10 ms·

I've been trying to use NodeJS after using Rails for years and it's just such a terrible experience. I don't want to install every basic package by hand and gen

I've been trying to use NodeJS after using Rails for years and it's just such a terrible experience. I don't want to install every basic package by hand and generate every model and view and controller by hand. This is basic boilerplate nonsense that made Rails so popular 15 years ago, and NodeJS throws away every lesson we learned from Rails. React is okay as a front-end but without a full stack framework, the current state of Javascript is like stepping back into 20 year old PHP development, where everyone just hacks together anything they can find with no structure, no convention, and no security.

martinlev 7y ago
Definitely agree with this. I have been switching from developing in ruby into Node 2 years ago as I thought this was "the new thing" for web apps. Now I just want to move away from Node. Large scale Node applications looks like 20 years ago, copy and paste all over the place, cheap libraries, no developer happiness, you have to reinvent the wheels, etc.
- selestify 7y ago
  Why did Node become so popular if this is the case?
  - deleted 7y ago
    [deleted]
  - lbotos 7y ago
    "WebScale" and a generation of programmers that grew up on Javascript thinking it would be cool to write JS on the server too.
  - laumars 7y ago
    Laziness I think. People wanted to use the same language for the backend as the frontend rather than picking their tools based on what does the job the best.
    - chrisweekly 7y ago
      Agreed that picking the right tool for the job is essential. But you might want to revisit your assumptions about the benefits of baking in such a hard separation of "frontend" and "backend". See Gatsby for example.
      - laumars 7y ago
        I know this might be an unpopular opinion but I personally think a hard separation is required because the frontend and backend development solve different problems. Sure they're related but it's like the distinction between SQL and backend web service code. Sure there are tools like ORMs however they never compare well to well written SQL from engineers who understand databases. Likewise understanding the distinction of requirements on the frontend vs backend is just as important. It's funny because many frontend web developers are keen to point out the distinction between Javascript, HTML and CSS and the importance of why HTML and CSS are distinctly different mark ups. Yet will then discuss frontend and backend code as if it's the same beast. Maybe this opinion is an age related thing though. I've been publishing websites since the 1990s ('93 I think my first site went live). So I've always seen frontend and backend as separate entities - as they were for most of the web's evolution.
        chrisweekly 7y ago
        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. "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. As is dismissing the real (and amazing) progress and expansion of possibilities inherent in the accelerating changes in front-end technology. Of course there are ignorant juniors. 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. But also progress, evolution, improvement. 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? "The difficulty lies not in grasping the new ideas, but letting go of the old."
  - RobertKerans 7y ago
    It's very easy to build small things with (small API servers, proxies, tools for example), development of those things is quick, the development feedback cycle is extremely rapid, JS is a bit of a lingua franca (for better or for worse), it is extremely easy to get set up (again, for simple things). In turn this created a huge community, which in turn triggered a virtuous (?) circle, and gave easily-installable libraries for almost anything you can think of. It also should be said that it is good at what it does. The reactor pattern works well in specific use cases and is easy to understand -- which I guess is the main cause of it being used as a general purpose hammer. Yes, it has glaring issues, but the "silly JS programmers with their toy language wanted to write backend servers" meme is a bit annoying.
  - martinlev 7y ago
    I believe for small projects it can be interesting, you can have an instance up using 50 MB ram. Also the language is widely used. JS is used in the frontend so they believe it's great for the backend also because you "reuse" the code. In my experience close no code is reused from frontend to the backend and vice versa.
  - smacktoward 7y ago
    Because there are an awful lot of JavaScript programmers out there, and Node let them apply the skills they already had on the server side for the first time [1]. [1] Technically, Node didn't invent server-side JavaScript; Netscape's application servers supported a version of the same idea in the '90s, back when Netscape was still a thing. But there was a long period where JS was effectively ghettoized as a language for browser scripting only, and Node is what broke it back out of that.
- winrid 7y ago
  What you're describing is just bad code. That happens in any runetime. This is not specific to Node.
  - martinlev 7y ago
    I agree, but from my observation bad code is more significantly more widespread in Node. The tooling is just incomplete by default, you have to setup yourself. Further the projects structure is completely different on every project (and typically not nicely done).
juliendc 7y ago
I can totally relate on this. In the end I think Rails and Node have different purposes. I would still use Node for proxy-style servers. Something with a small and focused scope which has to scale. For business intensive apps with a large scope, Rails-like frameworks are still way more productive and robust even if they are less trendy for the moment. The current frontend state is another story indeed. Frameworks like Ember tried to bring the same Rails-like structure to the frontend world but it isn't as popular and trendy as React for whatever reason. I think it's very costly for frontend teams to reinvent a coherent structure, convention etc for every new project. At least React has brought the same way of thinking in the frontend industry.
- nickserv 7y ago
  I'm new to the Rails ecosystem but from what I've seen and also with many years using Django (which is very similar), I would agree with your assessment regarding Rails. The complex monolith that speeds up development very much has its place, especially at the beginning of a project. You can always cut it apart later as needed. Regarding Node.js, however, I would say the pain is not worth it. For the same purpose I would now reach for Go (for networking stuff) or Rust (for high performance). This is after several years in a Node shop.
  - cutler 7y ago
    What about Elixir? Dynamically typed like Node and functional.
    - nickserv 7y ago
      Not a very easy sell to management, unfortunately. I'm using it for a personal project though, mainly thanks to Phoenix.
- cheez 7y ago
  Rails scales OK. You can't run Netflix on Rails on a single server, but it scales OK.
siquick 7y ago
Have a look at Sails.js. While not perfect, its highly influenced by Rails https://sailsjs.com/ https://sailsjs.com/
- ritchiea 7y ago
  What's the current state of Sails? I first heard about it 5 or 6 years ago but haven't heard much else about the project in ages.
  - duncan-donuts 7y ago
    I worked with node for 5 years and never came across anyone using sails. That might be a symptom of the node community but last I saw it still wasn’t very good.
- deviantfero 7y ago
  I'm currently working with it for a project atm, I can not recommend it, it's ORM is pretty bad, cutting corners wherever possible, but the worst thing about it is its documentation it is badly redacted and relies a lot on examples rather than laying out the possibilities of what you can do with a certain part of sails, issues also go unattended for a long while and there's not much of a community surrounding it. Just my two cents, I would be happy to hear some success stories from it though.
- geewee 7y ago
  I worked with sails about three years ago. It was a decent experience, but Sails 1.0 has been years underway and seems like a major rewrite of the whole thing. I don't really think a great many people use Sails anymore, and I don't think I would recommend it either.
- anm89 7y ago
  Sails is and has always been a subpar framework with a toxic community. The one time I tried to use it in production I regretted it big time.
winrid 7y ago
You're comparing a runtime environment to a framework. Use Angular on the client and something server side in Node and you're set. Use Typescript and you'll be able to refactor easily too. Nobody uses just React+Express w/o TS for something serious.
- cutler 7y ago
  "Nobody uses just React+Express w/o TS for something serious." Hardly. Just search for "(react.js or reactjs) (nodejs or node.js)" on indeed.co.uk. 441 results. Now append "-typescript" to the same search. 378 results. It appears Typescript hasn't yet taken over the world.
  - winrid 7y ago
    Maybe I should have said "... and has a good time." :)
  - addicted 7y ago
    Most companies using typescript don’t advertise for typescript developers and will simply look for JS decelopers, because the belief is that anyone should be able to transition from JS to TS so why limit your scope.
    - cutler 7y ago
      Where's your evidence for this?
- steve_adams_86 7y ago
  If you just use TS without really understanding how it can help you and your particular problems you're solving, it can be more of a burden to refactoring than a saviour. Type systems are not a panacea for refactoring difficulties.
  - winrid 7y ago
    How so? I wouldn't use it for a tiny app, but for something where you're thinking far into the future I would. Keep in mind, at my current company we don't use it (giant 5 year old AngularJS codebase) but I would love to. You don't even have to use it fully. Just mark your function arguments and you're already saving headaches.
burk96 7y ago
Speaking of PHP, I'm really enjoying using Laravel as of late. I'm not super experienced in web development, but the Laravel experience is my favorite so far. The Laracasts tutorial series is also top-notch. I really wish other projects had official video tutorials like them.
tekkk 7y ago
Like others have mentioned, this is an apple vs orange comparison. Ruby & Rails is not the same as NodeJS. 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. 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. You're complaining about frameworks, not NodeJS the runtime. And NodeJS is not fixed to some specific framework that forces you to do things in one way. And thank god for that. There was some initial burden I admit with NodeJS but I have at least got to the productive plateau (with TypeScript). Once you figure out the pattern that works for you, it gets simpler. The inventing part is what drives most developers crazy, and it did for me too. It's perhaps too non-restrictive but well, hopefully there's somebody in your company showing you the right way. 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. 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 yes, Rails has advantage with this but I think you made that argument clear. Instead of making the argument "NodeJS is bad" you should aim that at the frameworks of NodeJS. SailJS was a good attempt at Rails but it's way too restrictive with its patterns (and sadly the documentation is not good). Deno looks promising and I hope people will be building better frameworks on top of that.
- danpalmer 7y ago
  I think the point is more that a Rails style framework does not exist in Node. There are a few projects that have attempted to be like Rails, but none that appear to have succeeded in any real way. In the Ruby ecosystem, Rails will get you very far. In Python, Django will do the same. PHP –> Laravel. Scala –> Play. JS does not have an equivalent, and the community seems to actively dislike the approach. That's fine, a monolithic framework approach isn't always the best option, but in the Node ecosystem it's not even an option on the table.
  - tekkk 7y ago
    Well your argument is a lot more nuanced than the original comment I responded to. And I agree, it is burdensome especially for people not familiar with NodeJS that there isn't a one-size-fits-all framework. I don't really know the main causes why it happened, but I guess people felt satisfied with Express & Koa though it left, and still leaves, a lot for programmers to do by themselves. Perhaps because Express & Koa were "good enough" there never was a large enough momentum behind say SailJS to make it work. Nevertheless my experience with ORMs or scaffold generators has been that I always feel they are one custom use case away from turning from time-savers to time-sinks. When you write your own SQL and implement your own models/services or whatever abstraction you decide to use, you get a much deeper understanding of what is going on than just trusting your framework to do it for you. And is that good or bad? That is certainly a topic for debate.
sbmthakur 7y ago
I think it's better to compare Loopback/Express with Rails instead of NodeJS.
- cutler 7y ago
  From what I've seen of Loopback's verbosity I think the best comparison would be with Spring. For some reason every time the corporates get their hands on a dynamically-typed language they try their best to turn it into Java/C#. Facebook did it with PHP and now Microsoft are at it with Javascript.
specialist 7y ago
Completely differently origin stories. nodejs is JavaScript bindings for libev. http://software.schmorp.de/pkg/libev.html http://software.schmorp.de/pkg/libev.html Other comments listed npm modules with Rails equivalents, so I won't repeat. The one thing I got out of nodejs is becoming reacquainted with working closer to the metal. Minimalism for some HTTP endpoints (what the kids call REST) can be fun. Rails, PHP, nodejs et al, J2EE, etc. I've got no dog in this fight. Each is uniquely terrible. I hate them all.
earthboundkid 7y ago
I basically agree, but there are some people fighting the good fight against Node's awful ecosystem. - Parcel is like if Webpack were a build system and not a programming language to create a build system with. - Vue has good set of solutions. Nuxt is a nice version of "here's what you're probably going to want, already glued together." - If Deno ever becomes a thing, it will be cool. It feels like maybe if we're lucky, in five years, there will be an ecosystem for modern JS that doesn't suck.
z3t4 7y ago
It's too bad that Node.JS is mostly used as a scaffolding and glue language for web frameworks, while where it really shines is as a replacement for a systems language. You sacrifice 4x performance to get better safety, less development time, easier code, easier deployment, and a more open and friendly ecosystem.
- cutler 7y ago
  Replacement for a systems language? How are dynamically-typed callbacks, as in Node's fs library, in any way comparable with, say, go routines or good old procedural C++? Async is the worst programming model for building systems.
  - z3t4 7y ago
    The Node.JS libraries also have Sync (not async) alternatives. But everything is async by default. JS/Node is single threaded, but supports multi process concurrency with message passing and sharing of sockets. I personally prefer callback convention, but it's not the only paradigm. Primises/Futures, and async/await is also very popular. Node.JS makes you think async, which has a learning curve, but I prefer that over multi threading locks and data races. Go is also great. But I think JavaScript is much easier.
ollita7 7y ago
Hi how are? Why dont you give a try on kiwi serve. Its a framewrok I develop t work with node in a better way. You can check here www.kiwi-server.com. Of course It's open source

martinlev 7y ago

Definitely agree with this. I have been switching from developing in ruby into Node 2 years ago as I thought this was "the new thing" for web apps. Now I just want to move away from Node. Large scale Node applications looks like 20 years ago, copy and paste all over the place, cheap libraries, no developer happiness, you have to reinvent the wheels, etc.

selestify 7y ago
Why did Node become so popular if this is the case?
- deleted 7y ago
  [deleted]
- lbotos 7y ago
  "WebScale" and a generation of programmers that grew up on Javascript thinking it would be cool to write JS on the server too.
- laumars 7y ago
  Laziness I think. People wanted to use the same language for the backend as the frontend rather than picking their tools based on what does the job the best.
  - chrisweekly 7y ago
    Agreed that picking the right tool for the job is essential. But you might want to revisit your assumptions about the benefits of baking in such a hard separation of "frontend" and "backend". See Gatsby for example.
    - laumars 7y ago
      I know this might be an unpopular opinion but I personally think a hard separation is required because the frontend and backend development solve different problems. Sure they're related but it's like the distinction between SQL and backend web service code. Sure there are tools like ORMs however they never compare well to well written SQL from engineers who understand databases. Likewise understanding the distinction of requirements on the frontend vs backend is just as important. It's funny because many frontend web developers are keen to point out the distinction between Javascript, HTML and CSS and the importance of why HTML and CSS are distinctly different mark ups. Yet will then discuss frontend and backend code as if it's the same beast. Maybe this opinion is an age related thing though. I've been publishing websites since the 1990s ('93 I think my first site went live). So I've always seen frontend and backend as separate entities - as they were for most of the web's evolution.
      - chrisweekly 7y ago
        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. "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. As is dismissing the real (and amazing) progress and expansion of possibilities inherent in the accelerating changes in front-end technology. Of course there are ignorant juniors. 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. But also progress, evolution, improvement. 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? "The difficulty lies not in grasping the new ideas, but letting go of the old."
- RobertKerans 7y ago
  It's very easy to build small things with (small API servers, proxies, tools for example), development of those things is quick, the development feedback cycle is extremely rapid, JS is a bit of a lingua franca (for better or for worse), it is extremely easy to get set up (again, for simple things). In turn this created a huge community, which in turn triggered a virtuous (?) circle, and gave easily-installable libraries for almost anything you can think of. It also should be said that it is good at what it does. The reactor pattern works well in specific use cases and is easy to understand -- which I guess is the main cause of it being used as a general purpose hammer. Yes, it has glaring issues, but the "silly JS programmers with their toy language wanted to write backend servers" meme is a bit annoying.
- martinlev 7y ago
  I believe for small projects it can be interesting, you can have an instance up using 50 MB ram. Also the language is widely used. JS is used in the frontend so they believe it's great for the backend also because you "reuse" the code. In my experience close no code is reused from frontend to the backend and vice versa.
- smacktoward 7y ago
  Because there are an awful lot of JavaScript programmers out there, and Node let them apply the skills they already had on the server side for the first time [1]. [1] Technically, Node didn't invent server-side JavaScript; Netscape's application servers supported a version of the same idea in the '90s, back when Netscape was still a thing. But there was a long period where JS was effectively ghettoized as a language for browser scripting only, and Node is what broke it back out of that.
winrid 7y ago
What you're describing is just bad code. That happens in any runetime. This is not specific to Node.
- martinlev 7y ago
  I agree, but from my observation bad code is more significantly more widespread in Node. The tooling is just incomplete by default, you have to setup yourself. Further the projects structure is completely different on every project (and typically not nicely done).

juliendc 7y ago

I can totally relate on this. In the end I think Rails and Node have different purposes. I would still use Node for proxy-style servers. Something with a small and focused scope which has to scale. For business intensive apps with a large scope, Rails-like frameworks are still way more productive and robust even if they are less trendy for the moment. The current frontend state is another story indeed. Frameworks like Ember tried to bring the same Rails-like structure to the frontend world but it isn't as popular and trendy as React for whatever reason. I think it's very costly for frontend teams to reinvent a coherent structure, convention etc for every new project. At least React has brought the same way of thinking in the frontend industry.

nickserv 7y ago
I'm new to the Rails ecosystem but from what I've seen and also with many years using Django (which is very similar), I would agree with your assessment regarding Rails. The complex monolith that speeds up development very much has its place, especially at the beginning of a project. You can always cut it apart later as needed. Regarding Node.js, however, I would say the pain is not worth it. For the same purpose I would now reach for Go (for networking stuff) or Rust (for high performance). This is after several years in a Node shop.
- cutler 7y ago
  What about Elixir? Dynamically typed like Node and functional.
  - nickserv 7y ago
    Not a very easy sell to management, unfortunately. I'm using it for a personal project though, mainly thanks to Phoenix.
cheez 7y ago
Rails scales OK. You can't run Netflix on Rails on a single server, but it scales OK.

siquick 7y ago

Have a look at Sails.js. While not perfect, its highly influenced by Rails https://sailsjs.com/ https://sailsjs.com/

ritchiea 7y ago
What's the current state of Sails? I first heard about it 5 or 6 years ago but haven't heard much else about the project in ages.
- duncan-donuts 7y ago
  I worked with node for 5 years and never came across anyone using sails. That might be a symptom of the node community but last I saw it still wasn’t very good.
deviantfero 7y ago
I'm currently working with it for a project atm, I can not recommend it, it's ORM is pretty bad, cutting corners wherever possible, but the worst thing about it is its documentation it is badly redacted and relies a lot on examples rather than laying out the possibilities of what you can do with a certain part of sails, issues also go unattended for a long while and there's not much of a community surrounding it. Just my two cents, I would be happy to hear some success stories from it though.
geewee 7y ago
I worked with sails about three years ago. It was a decent experience, but Sails 1.0 has been years underway and seems like a major rewrite of the whole thing. I don't really think a great many people use Sails anymore, and I don't think I would recommend it either.
anm89 7y ago
Sails is and has always been a subpar framework with a toxic community. The one time I tried to use it in production I regretted it big time.

winrid 7y ago

You're comparing a runtime environment to a framework. Use Angular on the client and something server side in Node and you're set. Use Typescript and you'll be able to refactor easily too. Nobody uses just React+Express w/o TS for something serious.

cutler 7y ago
"Nobody uses just React+Express w/o TS for something serious." Hardly. Just search for "(react.js or reactjs) (nodejs or node.js)" on indeed.co.uk. 441 results. Now append "-typescript" to the same search. 378 results. It appears Typescript hasn't yet taken over the world.
- winrid 7y ago
  Maybe I should have said "... and has a good time." :)
- addicted 7y ago
  Most companies using typescript don’t advertise for typescript developers and will simply look for JS decelopers, because the belief is that anyone should be able to transition from JS to TS so why limit your scope.
  - cutler 7y ago
    Where's your evidence for this?
steve_adams_86 7y ago
If you just use TS without really understanding how it can help you and your particular problems you're solving, it can be more of a burden to refactoring than a saviour. Type systems are not a panacea for refactoring difficulties.
- winrid 7y ago
  How so? I wouldn't use it for a tiny app, but for something where you're thinking far into the future I would. Keep in mind, at my current company we don't use it (giant 5 year old AngularJS codebase) but I would love to. You don't even have to use it fully. Just mark your function arguments and you're already saving headaches.

burk96 7y ago

Speaking of PHP, I'm really enjoying using Laravel as of late. I'm not super experienced in web development, but the Laravel experience is my favorite so far. The Laracasts tutorial series is also top-notch. I really wish other projects had official video tutorials like them.

tekkk 7y ago

Like others have mentioned, this is an apple vs orange comparison. Ruby & Rails is not the same as NodeJS. 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. 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. You're complaining about frameworks, not NodeJS the runtime. And NodeJS is not fixed to some specific framework that forces you to do things in one way. And thank god for that. There was some initial burden I admit with NodeJS but I have at least got to the productive plateau (with TypeScript). Once you figure out the pattern that works for you, it gets simpler. The inventing part is what drives most developers crazy, and it did for me too. It's perhaps too non-restrictive but well, hopefully there's somebody in your company showing you the right way. 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. 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 yes, Rails has advantage with this but I think you made that argument clear. Instead of making the argument "NodeJS is bad" you should aim that at the frameworks of NodeJS. SailJS was a good attempt at Rails but it's way too restrictive with its patterns (and sadly the documentation is not good). Deno looks promising and I hope people will be building better frameworks on top of that.

danpalmer 7y ago
I think the point is more that a Rails style framework does not exist in Node. There are a few projects that have attempted to be like Rails, but none that appear to have succeeded in any real way. In the Ruby ecosystem, Rails will get you very far. In Python, Django will do the same. PHP –> Laravel. Scala –> Play. JS does not have an equivalent, and the community seems to actively dislike the approach. That's fine, a monolithic framework approach isn't always the best option, but in the Node ecosystem it's not even an option on the table.
- tekkk 7y ago
  Well your argument is a lot more nuanced than the original comment I responded to. And I agree, it is burdensome especially for people not familiar with NodeJS that there isn't a one-size-fits-all framework. I don't really know the main causes why it happened, but I guess people felt satisfied with Express & Koa though it left, and still leaves, a lot for programmers to do by themselves. Perhaps because Express & Koa were "good enough" there never was a large enough momentum behind say SailJS to make it work. Nevertheless my experience with ORMs or scaffold generators has been that I always feel they are one custom use case away from turning from time-savers to time-sinks. When you write your own SQL and implement your own models/services or whatever abstraction you decide to use, you get a much deeper understanding of what is going on than just trusting your framework to do it for you. And is that good or bad? That is certainly a topic for debate.

sbmthakur 7y ago

I think it's better to compare Loopback/Express with Rails instead of NodeJS.

cutler 7y ago
From what I've seen of Loopback's verbosity I think the best comparison would be with Spring. For some reason every time the corporates get their hands on a dynamically-typed language they try their best to turn it into Java/C#. Facebook did it with PHP and now Microsoft are at it with Javascript.

specialist 7y ago

Completely differently origin stories. nodejs is JavaScript bindings for libev. http://software.schmorp.de/pkg/libev.html http://software.schmorp.de/pkg/libev.html Other comments listed npm modules with Rails equivalents, so I won't repeat. The one thing I got out of nodejs is becoming reacquainted with working closer to the metal. Minimalism for some HTTP endpoints (what the kids call REST) can be fun. Rails, PHP, nodejs et al, J2EE, etc. I've got no dog in this fight. Each is uniquely terrible. I hate them all.

earthboundkid 7y ago

I basically agree, but there are some people fighting the good fight against Node's awful ecosystem. - Parcel is like if Webpack were a build system and not a programming language to create a build system with. - Vue has good set of solutions. Nuxt is a nice version of "here's what you're probably going to want, already glued together." - If Deno ever becomes a thing, it will be cool. It feels like maybe if we're lucky, in five years, there will be an ecosystem for modern JS that doesn't suck.

z3t4 7y ago

It's too bad that Node.JS is mostly used as a scaffolding and glue language for web frameworks, while where it really shines is as a replacement for a systems language. You sacrifice 4x performance to get better safety, less development time, easier code, easier deployment, and a more open and friendly ecosystem.

cutler 7y ago
Replacement for a systems language? How are dynamically-typed callbacks, as in Node's fs library, in any way comparable with, say, go routines or good old procedural C++? Async is the worst programming model for building systems.
- z3t4 7y ago
  The Node.JS libraries also have Sync (not async) alternatives. But everything is async by default. JS/Node is single threaded, but supports multi process concurrency with message passing and sharing of sockets. I personally prefer callback convention, but it's not the only paradigm. Primises/Futures, and async/await is also very popular. Node.JS makes you think async, which has a learning curve, but I prefer that over multi threading locks and data races. Go is also great. But I think JavaScript is much easier.

ollita7 7y ago

Hi how are? Why dont you give a try on kiwi serve. Its a framewrok I develop t work with node in a better way. You can check here www.kiwi-server.com. Of course It's open source