![]() Plus with tools like Docker, you can always scale sideways when your application failed to scale upwards. These days Javascript still doesn't support threading but it does have other primitives that do a reasonable job of compensating. However without tools like Docker nor any decent way of running parallel execution stacks (nor a first class web server supporting Node ala mod_perl / mod_php / phpfpm / et al) it meant Javascript was simply not a good language for backend development for a relatively long time because the tooling wasn't there and the language lacked the primitives to compensate (like how Python, Perl and Ruby could all self host their own threaded web server). In fact I'm pretty sure Node was just a hobby project where some guys thought "Chrome's JS VM can run headless - lets see where this takes us." (this part may be incorrect but I have a vague recollection of that being the case). But JS definitely did not suite backend development when Node was first being deployed. Plus in the early days we didn't need anything particularly pretty anyway. Javascript has always made some sense for frontend development - it might not be the best designed language from an academic perspective but it suited browser scripting well enough to get the job done. Let's also circle back to my point about the right tools for the job. frontend developers wanted to reuse the same language for front and back (often because they simply didn't want to learn another language). it was too difficult to get any other language first class support for browser scripting (the reasons for that are obvious)Ģ. So the reasons node gained any momentum in the early days was simply because:ġ. Back in the early days of Node it was complete garbage but people stuck with it because they wanted a single language to rule them all and browsers wouldn't support anything beyond JS (despite how crappy JS was back then). Your rhetoric - while lacking a lot of technical content - are valid for the current state of play but not the question being asked. I don't disagree that Javascript has evolved into a first class language now but it hasn't always been. ![]() "The difficulty lies not in grasping the new ideas, but letting go of the old." To write it all off, clinging to comforting notions that what we mastered a decade or more ago is the best - let alone only - way to do it? But also progress, evolution, improvement. Of course the signal:noise ratio in the world of modern web and mobile dev is suboptimal there's so much churn and noise and froth. As is dismissing the real (and amazing) progress and expansion of possibilities inherent in the accelerating changes in front-end technology. "The right tool for the job", yes, of course - but why would you insist that a particular set of traditional architectural constraints must needs be permanently enforced at the level of language and runtime? Being locked into a "3-tier architecture, server-side" perspective is a common trap for many senior developers. I think you misunderstood me, or we're talking past each other a bit here I've been at it professionally since about 1998, so any difference in perspective is unlikely to be age-related - at least in the sense of depth of experience with the tradition. Deno looks promising and I hope people will be building better frameworks on top of that. SailJS was a good attempt at Rails but it's way too restrictive with its patterns (and sadly the documentation is not good). Instead of making the argument "NodeJS is bad" you should aim that at the frameworks of NodeJS. And yes, Rails has advantage with this but I think you made that argument clear. And "code hacked together" is only a problem with bad programmers, you can get working and secure code with NodeJS, it just needs thought put into it. And you don't want to install every basic package by hand? But have them already included? You understand that adds quite a bit of bloat to projects that have no need for eg CORS or body-parser. It's perhaps too non-restrictive but well, hopefully there's somebody in your company showing you the right way. The inventing part is what drives most developers crazy, and it did for me too. Once you figure out the pattern that works for you, it gets simpler. There was some initial burden I admit with NodeJS but I have at least got to the productive plateau (with TypeScript). And NodeJS is not fixed to some specific framework that forces you to do things in one way. ![]() You're complaining about frameworks, not NodeJS the runtime. I agree that something like Rails has its own benefits, but I can't really take seriously this type of complaining when it's directed at the wrong thing. A popular framework which you probably used with NodeJS is Express, that as its documentation states tries to be a minimal framework for creating NodeJS servers. Like others have mentioned, this is an apple vs orange comparison.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |