Sails.js development has basically stagnated in the past year, and many people in the community believe Balderdash, the company behind it, aren't giving it the attention it deserves (they have a few new projects they're working on). Travis Webb and his team behind Trails were kicked out of Balderdash (not clear if fired from the company or just removed from GitHub group), and Travis blames Mike from Balderdash for doing it as a political move to keep control. Mike has said very little publicly about it, apparently not wanting to stir up more drama.
Trails seems to be an attempt at achieving what Sails has achieved (a full-stack modern MVC framework in node) with newer tools (ES6, I think Koa by default instead of Express, etc) and perhaps more modularity.
I think it's an ambitious project with good goals, but it will be a while before it will be stable and ready to use. And if it does reach that point, it's still susceptible to what's hurting Sails right now (a larger community than your developers can handle, de-prioritization, politics...).
Hopefully this turns out like the node / io.js split and is, in the end, positive for the ecosystem in some way.
> Hopefully this turns out like the node / io.js split and is, in the end, positive for the ecosystem in some way.
I agree. I commented earlier that the Node community seems to prefer small modules over Rails-like frameworks, but I think a solid web framework would be good for Node adoption by people who prefer them and beginners.
It will be awhile before it's fully production-ready of course, but we'll begin using it internally for developing new projects after our 1.0-beta release in February.
One note: we're using Hapi by default, but koa and express4 will be supported as well. This is part of our modularity difference.
The last time I checked in on Sails.js about 9 months ago, Mike McNeil, Cody Stoltman, and Scott Gress had just gotten back from YC for Treeline (http://treeline.io).[1]
>Trails is built and maintained by former members of the Sails.js core team
Just no. I was working with Sails.js for about a year now on production systems - it's horrible. Without a doubt I can say that it's the worst framework I've ever worked with. Especially their so called "orm" - we actually had to switch it off and work with pure mysql queries instead because it can't even do migrations (it deletes everything from db, stores in ram and re-insert).
Seriously, don't believe the hype, I bet this will be just as bad as Sails.
While I haven't played with Sails.JS, I've heard many people complain about how bad it was. However, just because the people building this new framework used to work on the Sails.JS Framework, you're going to dismiss it as being "automatically bad" ? I didn't look at Trails.JS so I don't know how it looks, but this kind of attitude seems extremely toxic and detrimental to the Open Source space. It makes me sad this is the top comment.
If anything, this gives them the chance to start anew, equipped with the knowledge of past mistakes, to avoid making them again.
I think it is only part of the core team, frustrated by the lack of progress on sails, so maybe they want some of the same changes you do. Also, while I had my own frustrations with waterline, the auto migrations were meant to speed up development, they were never meant to be used in production and can be turned off with a single line if code.
Sorry to hear you had a bad experience. The auto-migration support in Sails is a development-only feature, but for production, there is a great project from Danni Friedland called sails-migrations: https://github.com/BlueHotDog/sails-migrations
I try to stay away from big frameworks that try to do this very thing because development and production experiences are two completely different things. I've been through nightmares scenarios where things don't work correctly or new technical debt is introduced after deployment and smaller frameworks usually alleviate that pain point for me.
We'll be giving some talks on Trails the week of Jan 11th; we'll be visiting local Javascript groups in Detroit, Miami, and Los Angeles that week. If you're in the area, come hang out!
My new/current job is 100% JavaScript and I have been thinking to choose NodeJS and either React/EmberJS/AngularJS for my newbside project (a typical CRUD app) that I will have to maintain for a very long time. I almost chose Sails because Express is too low level/too simple.
Lately I've been reconsidering my options ever since there were a few HN posts related to my choice of stack that seem to conflict with my requirements: side project (meaning little effort) and long term maintenance (meaning stability, documentation should still exist for perhaps prior versions, relevant articles, examples from the Internet). Real time isn't a requirement, REST API isn't a requirements (yet), so I guess that minimize the need of NodeJS. I also haven't found a good case/example of code sharing between client and server side neither I heard people reaping tons of benefit from the principle since most front end framework forces the user to subscribe to their model/paradigm that may not work well with the back end code.
I quickly realized that perhaps Rails or the good old Java (with SpringMVC) seem to satisfy the requirement.
It's built on top of express.js and offers some of the more "Railsy" features that express lacks. Also supports this idea of shared models between the client and server (going for that whole code reuse thing you're talking about).
The company was also bought by IBM so I'm feeling pretty confident that it's going to keep getting regular updates and long-term support. They offer a bunch of enterprise-type features for the paid version, but the free one will be enough for your needs.
Why such decision-changing positive energy towards hapi? I am not saying you shouldn't, honestly asking why.
I have checked it, and I was not convinced of its superiority over express, considering the express community, modules, SO threads, etc. At least for a small-medium server.
Cargo cult nomenclature is a symptom of cargo cult architecture. They're already starting to run out of 6 letter words to name web frameworks with the format of "_rails". What's next: "Frails"? "Brails"? "Derails"? "Fails"? Or just "Ails"?
The phrase "Modern MVC Web Framework" is lipstick on a geriatric pig, like "Modern Waterfall Software Development Paradigm".
Unless by modern they mean modern as in modernism, that began in the 1870s as a self-consciousness and irony concerning literary and social traditions. [1]
In the same sense that the art style and technology in Fallout 4 is "modern". [2]
MVC frameworks might be better described as "Modern Googie GUI Architecture". [3]
"Things seem to hang on in computing just because they work a little bit." -Alan Kay on MVC [4]
I like how you differentiate from Sails such as ES6, and also the fact that you are much more community oriented.
Although I am not a JS fan for backend, I will give it a try next time instead of using Sails.
Awesome to see a project from the SailsJS team. SailsJS was the first MVC framework which I worked it and was extremely easy to begin with. Kudos for using ES6.
Sorry for the confusion. This isn't a project from us. Travis Webb (@tjwebb) was added as a contributor in mid-2015, but unfortunately it did not work out. The only contributor who was removed from Sails was Travis, in late November. And ever since, he has been doing everything he can to discredit our project, including claiming that the Sails team is working on Trails, or that Sails is "abandoned". Travis is the _only_ former Sails contributor (i.e. someone with actual write access to our repos) working on Trails.
If you have a technical problem with Sails, bring that up with me or another member of our core team on GitHub. But please realize that this fork is not about technical issues; it is a personal vendetta against me and the Sails.js project.
[+] [-] clay_to_n|10 years ago|reply
Sails.js development has basically stagnated in the past year, and many people in the community believe Balderdash, the company behind it, aren't giving it the attention it deserves (they have a few new projects they're working on). Travis Webb and his team behind Trails were kicked out of Balderdash (not clear if fired from the company or just removed from GitHub group), and Travis blames Mike from Balderdash for doing it as a political move to keep control. Mike has said very little publicly about it, apparently not wanting to stir up more drama.
Trails seems to be an attempt at achieving what Sails has achieved (a full-stack modern MVC framework in node) with newer tools (ES6, I think Koa by default instead of Express, etc) and perhaps more modularity.
I think it's an ambitious project with good goals, but it will be a while before it will be stable and ready to use. And if it does reach that point, it's still susceptible to what's hurting Sails right now (a larger community than your developers can handle, de-prioritization, politics...).
Hopefully this turns out like the node / io.js split and is, in the end, positive for the ecosystem in some way.
[+] [-] sotojuan|10 years ago|reply
I agree. I commented earlier that the Node community seems to prefer small modules over Rails-like frameworks, but I think a solid web framework would be good for Node adoption by people who prefer them and beginners.
[+] [-] traviswebb|10 years ago|reply
One note: we're using Hapi by default, but koa and express4 will be supported as well. This is part of our modularity difference.
[+] [-] stephengoodwin|10 years ago|reply
[1] https://www.crunchbase.com/organization/the-treeline-company
[+] [-] romanovcode|10 years ago|reply
Just no. I was working with Sails.js for about a year now on production systems - it's horrible. Without a doubt I can say that it's the worst framework I've ever worked with. Especially their so called "orm" - we actually had to switch it off and work with pure mysql queries instead because it can't even do migrations (it deletes everything from db, stores in ram and re-insert).
Seriously, don't believe the hype, I bet this will be just as bad as Sails.
[+] [-] roblabla|10 years ago|reply
If anything, this gives them the chance to start anew, equipped with the knowledge of past mistakes, to avoid making them again.
[+] [-] kevinob11|10 years ago|reply
[+] [-] mikermcneil|10 years ago|reply
You might also want to check out sails-db-migrate: https://github.com/building5/sails-db-migrate
At Treeline, we're using sails-migrations in production.
[+] [-] paulddraper|10 years ago|reply
[+] [-] dimgl|10 years ago|reply
[+] [-] _____s|10 years ago|reply
A newer framework from the same people has at least one thing going for them: they aren't likely to make the same mistakes.
[+] [-] traviswebb|10 years ago|reply
Keep in mind that Trails.js is pre-release. We're releasing 1.0-alpha on January 8, which isn't too far away. For more info on our development schedule, see our roadmap: https://github.com/trailsjs/trails/blob/master/ROADMAP.md
We'll be giving some talks on Trails the week of Jan 11th; we'll be visiting local Javascript groups in Detroit, Miami, and Los Angeles that week. If you're in the area, come hang out!
[+] [-] Raed667|10 years ago|reply
[0]: https://courses.platzi.com/courses/develop-apps-sails-js/
[+] [-] catmanjan|10 years ago|reply
[+] [-] pdappollonio|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] edwinnathaniel|10 years ago|reply
Lately I've been reconsidering my options ever since there were a few HN posts related to my choice of stack that seem to conflict with my requirements: side project (meaning little effort) and long term maintenance (meaning stability, documentation should still exist for perhaps prior versions, relevant articles, examples from the Internet). Real time isn't a requirement, REST API isn't a requirements (yet), so I guess that minimize the need of NodeJS. I also haven't found a good case/example of code sharing between client and server side neither I heard people reaping tons of benefit from the principle since most front end framework forces the user to subscribe to their model/paradigm that may not work well with the back end code.
I quickly realized that perhaps Rails or the good old Java (with SpringMVC) seem to satisfy the requirement.
[+] [-] sebular|10 years ago|reply
It's built on top of express.js and offers some of the more "Railsy" features that express lacks. Also supports this idea of shared models between the client and server (going for that whole code reuse thing you're talking about).
The company was also bought by IBM so I'm feeling pretty confident that it's going to keep getting regular updates and long-term support. They offer a bunch of enterprise-type features for the paid version, but the free one will be enough for your needs.
[+] [-] _qbjt|10 years ago|reply
[+] [-] kevindeasis|10 years ago|reply
Then I saw a point where they were using hapijs in their module: https://github.com/hapijs/hapi
That is giving me a small motivation to try some of my future weekend projects with Trails.
[+] [-] sirodoht|10 years ago|reply
I have checked it, and I was not convinced of its superiority over express, considering the express community, modules, SO threads, etc. At least for a small-medium server.
[+] [-] andrewchambers|10 years ago|reply
[+] [-] harunurhan|10 years ago|reply
[+] [-] chvid|10 years ago|reply
[+] [-] DonHopkins|10 years ago|reply
[+] [-] p0larboy|10 years ago|reply
[+] [-] DonHopkins|10 years ago|reply
The phrase "Modern MVC Web Framework" is lipstick on a geriatric pig, like "Modern Waterfall Software Development Paradigm".
Unless by modern they mean modern as in modernism, that began in the 1870s as a self-consciousness and irony concerning literary and social traditions. [1]
In the same sense that the art style and technology in Fallout 4 is "modern". [2]
MVC frameworks might be better described as "Modern Googie GUI Architecture". [3]
"Things seem to hang on in computing just because they work a little bit." -Alan Kay on MVC [4]
[1] https://en.wikipedia.org/wiki/Modernism
[2] http://img.duniaku.net/wp-content/uploads/2015/06/Fallout-4-...
[3] https://en.wikipedia.org/wiki/Googie_architecture
[4] https://news.ycombinator.com/item?id=7755759
[+] [-] harunurhan|10 years ago|reply
[+] [-] manojlds|10 years ago|reply
[+] [-] always_good|10 years ago|reply
[+] [-] sotojuan|10 years ago|reply
[+] [-] z1mm32m4n|10 years ago|reply
[+] [-] bhanu423|10 years ago|reply
[+] [-] mikermcneil|10 years ago|reply
If you have a technical problem with Sails, bring that up with me or another member of our core team on GitHub. But please realize that this fork is not about technical issues; it is a personal vendetta against me and the Sails.js project.
[+] [-] mikemaccana|10 years ago|reply
[+] [-] stephengoodwin|10 years ago|reply
[+] [-] anodari|10 years ago|reply
[+] [-] hmans|10 years ago|reply
[+] [-] rphl|10 years ago|reply
[deleted]