3 ms·

I will go ahead and add some points and disagree with other points. 1. I believe that the best path is to start from the top. Start with the most user-facing s

I will go ahead and add some points and disagree with other points. 1. I believe that the best path is to start from the top. Start with the most user-facing side of the tech stack, the client-side. Why? Because further down the stack (esp. deployment and DBs), there are more and more modern services/libraries that abstract things away. So things like Parse, Firebase, ORMS, Heroku, hosted DBs, MongoHQ, etc. I'm not saying you should never learn these things, just that in terms of getting an app out the door really quickly, the client-side is the most important piece. 2. Agreed with sentiments on this thread about starting with Bootstrap and jQuery. I'll chime in and say that while I greatly prefer Angular to Backbone, Backbone can be fairly educational. If you find Backbone frustrating, check out AngularJS. Whether or not you use an html templating language or CSS preprocessor is really up to personal choice. I'd start with bare HTML honestly. Although CSS is enough of a pain to code in that I'd recommend SCSS from the get-go. 3. I'll be pedantic for a bit and point out that Node.js is not a framework - it's a runtime environment for JS with some additional standard libs (like a barebones http library). You almost certainly need something like Express. 4. Here things diverge a bit. I'm a big fan of node.js. But let's be clear about what your goals are. If you want to get employed at a startup, Rails is vastly more popular and widely used than node.js, and for good reasons. So if that is your goal, that should be a clear winner. But if that doesn't concern you, or if you're too lazy to learn Ruby, I wholeheartedly endorse starting with node on the server-side. You get to focus your energy on one language, get to share your IDEs, tooling, and testing setup between the client and server, and get something that's highly scalable to boot.

anonyfox 13y ago
1. Oh, i personally start from top, too. But the people around me tend to start from the bottom, because most of them are used to rails. You know, choose a datastore and start modeling/scaffolding right away, it's the rails way. That's why I inverted this in my post. I agree with you - the client is the most important thing to think about. When all is said and done only the client experience matters for your customers. 2. Of course, there are many solutions out there. I especially like Backbone for it's minimalistic nature, forcing you to nothing else than using something jQuery-ish thing. Since it's written by the same guys that wrote coffeescript (i prefer over JS), i like the combination of both. subtile thingie. 3. Yeah, of course it's not a real framework. But for some usecases, like providing special APIs, pure node.js without express might be enough. If not, you may pick express or anything on top of it. (most frameworks seem to be built on top of express nowadays) 4. Well both know that rails won't die the next years or even centuries. Personally i am currently employed as a Rails developer and see the mindshift... slowly but steady. Many developers are playing with it, don't find it amazing first time ("nothing new to see here, i can do this too with language XYZ"), but after some time passed, they realize what's different and they're impressed more and more. Especially startups that built their first release with a classic rails/mysql-stack and need to (often struggling to) scale seem to be interested to switch over. Finally, the most important point is: master JavaScript. This includes (!) stuff like Coffeescript if you like it. And then look at the vast and emerging ecosystem around it. If you don't need rocketscience-numbercrunching and/or don't have the tight constraints of embedded systems, nearly everything is possible. Take any other "server"-language, and you'll have to deal with tons of Javascript anyways. Just remove the mental burden you'd have with additional (fading?) ecosystems.
- svermeulen 13y ago
  Thank you both for your fantastic answers. I now have a roadmap.
- argonaut 13y ago
  3. I think pure node.js is pretty much never a good choice. Express.js or alternatives like restify are lightweight enough that there are virtually no cases in which using those would be "too much." In fact, that is precisely Express.js's weakness - people say that Express is like Sinatra, when the truth is that Express has even fewer features then Sinatra. That being said, I personally learned node.js by starting with raw node (and the http module).

anonyfox 13y ago

1. Oh, i personally start from top, too. But the people around me tend to start from the bottom, because most of them are used to rails. You know, choose a datastore and start modeling/scaffolding right away, it's the rails way. That's why I inverted this in my post. I agree with you - the client is the most important thing to think about. When all is said and done only the client experience matters for your customers. 2. Of course, there are many solutions out there. I especially like Backbone for it's minimalistic nature, forcing you to nothing else than using something jQuery-ish thing. Since it's written by the same guys that wrote coffeescript (i prefer over JS), i like the combination of both. subtile thingie. 3. Yeah, of course it's not a real framework. But for some usecases, like providing special APIs, pure node.js without express might be enough. If not, you may pick express or anything on top of it. (most frameworks seem to be built on top of express nowadays) 4. Well both know that rails won't die the next years or even centuries. Personally i am currently employed as a Rails developer and see the mindshift... slowly but steady. Many developers are playing with it, don't find it amazing first time ("nothing new to see here, i can do this too with language XYZ"), but after some time passed, they realize what's different and they're impressed more and more. Especially startups that built their first release with a classic rails/mysql-stack and need to (often struggling to) scale seem to be interested to switch over. Finally, the most important point is: master JavaScript. This includes (!) stuff like Coffeescript if you like it. And then look at the vast and emerging ecosystem around it. If you don't need rocketscience-numbercrunching and/or don't have the tight constraints of embedded systems, nearly everything is possible. Take any other "server"-language, and you'll have to deal with tons of Javascript anyways. Just remove the mental burden you'd have with additional (fading?) ecosystems.

svermeulen 13y ago
Thank you both for your fantastic answers. I now have a roadmap.
argonaut 13y ago
3. I think pure node.js is pretty much never a good choice. Express.js or alternatives like restify are lightweight enough that there are virtually no cases in which using those would be "too much." In fact, that is precisely Express.js's weakness - people say that Express is like Sinatra, when the truth is that Express has even fewer features then Sinatra. That being said, I personally learned node.js by starting with raw node (and the http module).