4 ms·

It seems like you're comparing a framework with a language? What framework do you use on node.js? My experience with nodejs has been pretty poor. I'll give s

by anko 9y ago

It seems like you're comparing a framework with a language? What framework do you use on node.js? My experience with nodejs has been pretty poor. I'll give some examples; * The language and runtime is constantly updating - there is no such thing as stability * Even npm couldn't produce deterministic installs until this year * npm dependency hell * there are lots of ways to do any task, so there is much fragmentation with advice / community * the repls in node suck compared to pry * I can't find a good opinionated framework - so everyone lays out each application differently, with different standards etc. That means you end up spending a ridiculous amount of time configuring everything. * most apps i've needed to make don't actually benefit from being a SPA. It's a cargo cult thing. * javascript as a language sucks!

ishanjain28 9y ago
This is exactly all the pain points I had with node. Left it about a year ago, Forever.
Shicholas 9y ago
GraphQL and Express (wrapped with AWS Lambda's express handler for deploys) To answer your points: * You're right it hasn't been - but it is now with LTS releases of Node. * I agree, this is why I use yarn. * Yarn has solved any dependency issues I've witnessed. * While this is true, every solution boils down to simple objects or simple functions. New solutions tend to be simpler than the status quo (e.g. redux) * While debugging isn't as easy - all my back-end code boils down to simple functions which just need a simple test (I use mocha which is a lot like RSpec). Also Typescript and TSLint enforce types and code styling so I don't really need the pry-style debugging. * The only configuration I feel you need is Typescript and TSLint which will enforce a very specific way of styling code, file naming conventions and so much more. From there my individual functions representing GraphQL mutations and queries on the back-end or React components on the front-end are small, modular, and encapsulated in a folder to make for an easy `cp -vr`. * You're only talking about web. React Native/VR are extremely compelling reasons to expand beyond just the browser. Plus I feel separation of front/back-end makes for faster product development on bigger teams. * Haha yes, though ES2015 made it a lot better and Typescript has made it complete IMO. Microsoft and Google have both made substantial investments into the language, with the former making it as big of a center-point as C#. That's saying something. You can code Typescript code on a cheaper and faster Windows machine, ruby? much more difficult.

by anko 9y ago

ishanjain28 9y ago

This is exactly all the pain points I had with node. Left it about a year ago, Forever.

Shicholas 9y ago

GraphQL and Express (wrapped with AWS Lambda's express handler for deploys) To answer your points: * You're right it hasn't been - but it is now with LTS releases of Node. * I agree, this is why I use yarn. * Yarn has solved any dependency issues I've witnessed. * While this is true, every solution boils down to simple objects or simple functions. New solutions tend to be simpler than the status quo (e.g. redux) * While debugging isn't as easy - all my back-end code boils down to simple functions which just need a simple test (I use mocha which is a lot like RSpec). Also Typescript and TSLint enforce types and code styling so I don't really need the pry-style debugging. * The only configuration I feel you need is Typescript and TSLint which will enforce a very specific way of styling code, file naming conventions and so much more. From there my individual functions representing GraphQL mutations and queries on the back-end or React components on the front-end are small, modular, and encapsulated in a folder to make for an easy `cp -vr`. * You're only talking about web. React Native/VR are extremely compelling reasons to expand beyond just the browser. Plus I feel separation of front/back-end makes for faster product development on bigger teams. * Haha yes, though ES2015 made it a lot better and Typescript has made it complete IMO. Microsoft and Google have both made substantial investments into the language, with the former making it as big of a center-point as C#. That's saying something. You can code Typescript code on a cheaper and faster Windows machine, ruby? much more difficult.