Re:Why we choose Java instead of a polyglot stack
by sotojuan on Thursday January 21, 2016 @04:51PM
(#10948685)
Express isn't like Rails. It's more like Sinatra, but has probably even less stuff. There's no official or popular Rails for Node yet. People have made stuff like Sails but not many use it.
[ Parent
| on HN ]
Re:Why we choose Java instead of a polyglot stack
by edwinnathaniel on Thursday January 21, 2016 @04:58PM
(#10948762)
Keep in mind Sails has stagnated and there's a fork called TrailJS now.
The NodeJS 3rd-party ecosystem is really really fragile at the moment.
Re:Why we choose Java instead of a polyglot stack
by sotojuan on Thursday January 21, 2016 @05:15PM
(#10948896)
Yeah that's what I meant. The Node ecosystem doesn't really care for Rails-like frameworks so they stagnate. Most Ruby companies run Rails. Most Node companies run Express, Hapi, or Koa. Not Sails.
Re:Why we choose Java instead of a polyglot stack
by traviswebb on Saturday January 23, 2016 @08:47PM
(#10961092)
For anyone who's interested, the github repo: https://github.com/trailsjs/trails
Re:Why we choose Java instead of a polyglot stack
by seivan on Thursday January 21, 2016 @05:10PM
(#10948847)
It's rails like through its middleware pipeline design. That's a requirement for me.
That allows Express third party middleware to add missing parts like Strong Params and easier HTTP Caching.
It would be nice to have batteries included but not at the cost of a giant box still design that I suspect Sails and other have. Pipeline design is important and Express does that really good.
Re:Why we choose Java instead of a polyglot stack
by sotojuan on Thursday January 21, 2016 @05:14PM
(#10948891)
Gotcha, thought you meant something else. Thanks for clearing it up. Have you looked into koa[1]?
Re:Why we choose Java instead of a polyglot stack
by seivan on Thursday January 21, 2016 @08:33PM
(#10950111)
Koajd has the same problem Express.js has, its batteries/middleware are not Omakase first class but third party. So I expect friction as things move forward in terms of updates. Ever dealt with RubyGems when upgrading Rails?
Imagine if your core app consisted of all different third party libs and you wanna update Express/Koa?
Then we have typedefinitions for all those libraries. Which why I'm looking for alternatives with typed languages.
You might have misunderstood my question or I'm getting things wrong again. :-)