|
EVGA Longoria posted:i used node.js for a project the other day shhhhh just embrace it it's OK to do things that feel good even if others say they should feel bad edit: unless we're talking PHP or node.js for a non-trivial server. don't do that no matter how good it might feel Damiya fucked around with this message at 20:28 on Mar 9, 2014 |
#
?
Mar 9, 2014 20:25
|
|
|
|
| # ? Jun 12, 2024 15:38 |
|
|
the only moral nodejs is my nodejs
|
|
#
?
Mar 9, 2014 20:29
|
|
|
Dicky B posted:a baby could do this Most programming things can be done by a baby i was serious about the php. Setting up additional server software is retarded if you just want to template your header/footer. The cutoff for php is when you cannot reasonably add it as a 1-liner directly into html.
|
|
#
?
Mar 9, 2014 22:05
|
|
|
MeruFM posted:Most programming things can be done by a baby the problem with using php for dumb poo poo like this is that it's not really any better than just a dumb cgi script or using a template library to render statically effort spent with php is just wasted
|
|
#
?
Mar 9, 2014 22:09
|
|
|
django trip report: good poo poo 
|
|
#
?
Mar 9, 2014 23:07
|
|
|
the one poo poo thing i discovered is for some reason django uses php's datetime format strings instead of python's 
|
|
#
?
Mar 9, 2014 23:10
|
|
|
MeruFM posted:Most programming things can be done by a baby Alternatively you could just use something like jekyll and not be doing PHP. if your goal is to template use a template system that generates static output. if your goal is to do dynamic content, don't do PHP. there is no reason to use PHP in 2014
|
|
#
?
Mar 10, 2014 02:23
|
|
|
Damiya posted:shhhhh just embrace it
|
|
#
?
Mar 10, 2014 02:27
|
|
|
Bloody posted:if it works then who gives a poo poo p much
|
|
#
?
Mar 10, 2014 04:28
|
|
|
there's been more discussion than it would take to just make the site in every single one of the technologies mentioned so far
|
|
#
?
Mar 10, 2014 04:35
|
|
|
Bloody posted:if it works then who gives a poo poo future you when you have to maintain it
|
|
#
?
Mar 10, 2014 04:46
|
|
|
tef posted:future you when you have to maintain it the worst part of personal projects is confronting the fact that all the horrible legacy code was you. you did it to yourself
|
|
#
?
Mar 10, 2014 04:50
|
|
|
Gazpacho posted:where do you work that trivial projects don't always grow into lumbering monstrosities when i say trivial i mean like "this node server only gets spawned by gulp for the purposes of serving static assets so i can test some static poo poo" and not ever "this node server is a thing and will be maintained and also is in production,  " because when you cross that line and make a thing in node that's not a basic tool you've hosed up.
|
|
#
?
Mar 10, 2014 04:56
|
|
|
Damiya posted:when i say trivial i mean like "this node server only gets spawned by gulp for the purposes of serving static assets so i can test some static poo poo" your inexperience is showing one of these things leads to the other. not inexorably, but often enough to make us all suffer
|
|
#
?
Mar 10, 2014 05:14
|
|
|
Damiya posted:when i say trivial i mean like "this node server only gets spawned by gulp for the purposes of serving static assets so i can test some static poo poo" all prototypes end up in production. your nodejs server and your php 1 liners will inevitably metastasize. you can make the right choice up front, you can do the hard work of fixing deep seated architectural problems in production, or you can deal with maintaining a piece of poo poo forever. that's it. that's all there is.
|
|
#
?
Mar 10, 2014 07:16
|
|
|
also good luck with number one and number two will introduce more problems than it solves. everything is horrible and life is ultimately futile. pray for a quick and painless death.
|
|
#
?
Mar 10, 2014 07:23
|
|
|
no node.js ever, for any reason. ever. what is so hard to understand about this
|
|
#
?
Mar 10, 2014 09:20
|
|
|
JewKiller 3000 posted:no node.js ever, for any reason. ever. what is so hard to understand about this but then how will i use my tessel
|
|
#
?
Mar 10, 2014 09:25
|
|
|
hahaha and also ughghgh the domain ends in .io so you know it's gonna be good
|
|
#
?
Mar 10, 2014 09:26
|
|
|
you will always maintain a piece of poo poo forever, things that are not pieces of poo poo will not need maintaining and the free market will then force out onto some other piece of poo poo just relax and try to enjoy this personal hell you have chosen for yourself
|
|
#
?
Mar 10, 2014 09:47
|
|
|
HORATIO HORNBLOWER posted:all prototypes end up in production. your nodejs server and your php 1 liners will inevitably metastasize. you can make the right choice up front, you can do the hard work of fixing deep seated architectural problems in production, or you can deal with maintaining a piece of poo poo forever. that's it. that's all there is. i don't think you or notorious bsd understand. the case of using node for front-end asset compilation is totally removed from using it as an application server. she's not using node as a "prototype": she's using node as part of build process, probably running on a CI server somewhere to produce some part of an artifact to be deployed, like many others do in concert with a python or java or scala or ruby or god-knows-what-else application server.
|
|
#
?
Mar 10, 2014 10:20
|
|
|
why would you be stuck maintaining something when you can just do greenfield projects and let other people maintain it and then complain about it in the cjs thread while you move on to new stuff
|
|
#
?
Mar 10, 2014 11:18
|
|
|
Deus Rex posted:i don't think you or notorious bsd understand. the case of using node for front-end asset compilation is totally removed from using it as an application server. she's not using node as a "prototype": she's using node as part of build process, probably running on a CI server somewhere to produce some part of an artifact to be deployed, like many others do in concert with a python or java or scala or ruby or god-knows-what-else application server. the price of using bad things is that someone will see that they work and use more bad things, nonlinearly more in the case of really bad things, because you'll throw more crap on to patch the leaks. historically there's a little wiggle room w.r.t. builds, because builds are usually cobbled from the discount parts bin (use maven and be double-disgusted by miserable piles of build scripts). but changing your build system that no one maintains beyond minimal effort patches not a thing that happens without tremendous expenditures in time and energy, which also guarantees that it stays in that maximally awful way. say no to drugs
|
|
#
?
Mar 10, 2014 12:03
|
|
|
node is fine for minifying/compressing/processing web assets because the front end world moves too fast for most other platforms to be viable. you're thinking about it incorrectly if you think it needs to be stable. it's just a part of your jenkins build and it helps your ux people work faster and better so what is the problem. they're better than you at design and you're better than them at backend
|
|
#
?
Mar 10, 2014 12:23
|
|
|
MeramJert posted:but then how will i use my tessel aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
|
#
?
Mar 10, 2014 12:39
|
|
|
compuserved posted:this is pretty great, thanks HORATIO HORNBLOWER posted:all prototypes end up in production. your nodejs server and your php 1 liners will inevitably metastasize. you can make the right choice up front, you can do the hard work of fixing deep seated architectural problems in production, or you can deal with maintaining a piece of poo poo forever. that's it. that's all there is.
|
|
#
?
Mar 10, 2014 12:59
|
|
|
MeramJert posted:Aimed squarely in the gap between the Arduino at the low end, and the Raspberry Pi at the high end, both these boards use Javascript as their programming language, and both use it as close to the metal as possible. question for the people who actually know things: how "close to the metal" can you actually get? how many layers of machine/assembly language are required for any given piece of hardware?
|
|
#
?
Mar 10, 2014 13:15
|
|
|
prefect posted:question for the people who actually know things: how "close to the metal" can you actually get? how many layers of machine/assembly language are required for any given piece of hardware? one unless you count fpgas then... half? in a normal micro you just fart some machine code into some memory and when it powers on the program counter always starts at some known value and it just starts doing whatever it finds at that spot in memory and off it goes, executing your poo poo code also just lol at calling a raspberry fart high end, poo poo is a thirty dollar steaming turd quote:In-house we’ve developed a JavaScript interpreter built around the Lua runtime that is compatible with the Node.js API. No native C++ modules, but control flow and HTTP modules easily. Our OS is effectively an event loop on the bare metal. jesus christ what the gently caress
|
|
#
?
Mar 10, 2014 13:55
|
|
|
HORATIO HORNBLOWER posted:all prototypes end up in production. your nodejs server and your php 1 liners will inevitably metastasize. you can make the right choice up front, you can do the hard work of fixing deep seated architectural problems in production, or you can deal with maintaining a piece of poo poo forever. that's it. that's all there is. mvc5 is better and easier than either of those choices so theres no real reason to use them ever.
|
|
#
?
Mar 10, 2014 13:57
|
|
|
prefect posted:question for the people who actually know things: how "close to the metal" can you actually get? how many layers of machine/assembly language are required for any given piece of hardware? in principle you could run a minimal javascript vm on bare metal, sure. write a garbage collector, bytecode compiler, and interpreter, and you can shuffle js objects around in sram easily enough. add a couple of pseudo-arrays called say _MEM and _IRQ, where _MEM's indices map to physical addresses in the address space and assigning closures to _IRQ indices transparently generates thunking interrupt vectors that call back into the vm. in principle you could write all of your device drivers and application code in this way. in practice, of course, it would be really impractical. a high-end microcontroller has maybe 128KB of RAM, and js is a memory glutton. you could of course get a high-end microcontroller with a DRAM controller and slap a couple gigs of DDR onto your board, but i'd say the point at which your poo poo has a DRAM controller is the point at which it stops being a microcontroller and starts being an application processor (well, that and the presence of virtual memory i suppose). isrs thunked into the javascript vm would have unacceptably high latency for anything more complicated than blinking leds or a timer capture/compare. consider usb for example; the "frame rate" of usb is 1 kHz, and depending on what your device is doing you could easily overcommit your cpu just acknowledging bus traffic. so, practical considerations dictate that at least some of your drivers need to be written in c. also if you want to run a webserver through its usb port then you'd need a fairly deep stack of usb device, rndis, ip, tcp, http etc. tcp in particular is apparently surprisingly complicated and hard to get right. also don't forget that every number in javascript is a double. mcus aren't exactly known for their double-precision floating-point performance. you could handwave it and say "oh, they're all 32-bit ints on this platform" but then that's not javascript anymore, it's an incompatible dialect of javascript that sucks less.
|
|
#
?
Mar 10, 2014 14:06
|
|
|
also don't forget that javascript is terrible
|
|
#
?
Mar 10, 2014 14:07
|
|
|
i dont think we forgot shaggar. we were just discussing that
|
|
#
?
Mar 10, 2014 14:11
|
|
|
Mr Dog posted:also if you want to run a webserver through its usb port then you'd need a fairly deep stack of usb device, rndis, ip, tcp, http etc. tcp in particular is apparently surprisingly complicated and hard to get right. tcp has all the reliability/error-checking stuff, so it's not that surprising that it's hard also, thanks for the info 
|
|
#
?
Mar 10, 2014 14:13
|
|
|
i sort of imagine that they actually run contiki or such, or if they don't they are being rather stupid and should writing tiny compliant tcp/ip stacks is non-trivial stuff and the contiki guys have it p. well figured out
|
|
#
?
Mar 10, 2014 14:30
|
|
|
Deus Rex posted:i don't think you or notorious bsd understand. the case of using node for front-end asset compilation is totally removed from using it as an application server. she's not using node as a "prototype": she's using node as part of build process, probably running on a CI server somewhere to produce some part of an artifact to be deployed, like many others do in concert with a python or java or scala or ruby or god-knows-what-else application server. that's very much "in production" even if the audience is internal rather than external. if your external product deserves to be written in a real language and with a maintainable process then your internal product does too. there's no excuse for using this poo poo anywhere except for utter laziness and a complete lack of care. if you're moving on to the next thing in a year and you feel nothing but spite for your fellow man who will have to deal with this garbage after you're gone go right ahead. but don't pretend it's ok because it's "just" part of your build process, as if that were something minor and inconsequential.
|
|
#
?
Mar 10, 2014 14:41
|
|
|
lol if your build process isnt pressing the "build" button in visual studio
|
|
#
?
Mar 10, 2014 14:57
|
|
|
when I want to get close to the metal I choose js
|
|
#
?
Mar 10, 2014 15:08
|
|
|
The best thing I can say about visual studio is that it isn't terrible I guess. gotta love c# enums. "Hey let's have a strongly-typed enum facility in our language that actually isn't strongly typed at all fart fart fart fart" (you can cast arbitrary integers to enum types in c# and they're basically little more than reflective sugar for ints. whereas java treats the possible values of enums as opaque global static instances of that enum type instead. java: doing the poo poo that c# rushed out the door first, properly)
|
|
#
?
Mar 10, 2014 15:19
|
|
|
|
| # ? Jun 12, 2024 15:38 |
|
|
ya c# enums are poo poo.
|
|
#
?
Mar 10, 2014 15:26
|
|