Trails – Modern MVC Web Framework for Node.js
github.com
github.com
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.
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.
Trails is actually much more modular than Sails. The goal is the same -- to make your life easier -- and the conventions are rails-like (indeed, compatible wiyh Sails) but the technical design is completely different and actually quite a bit more "node-like".
Keep in mind that Trails is not a fork, but a Sails-compatible re-write. So there's no upstream code-level reconciliation that can happen, but I'm sure both projects can coexist and compete in the framework market on their merits.
The same could have been said of Rails and Merb back in the day, but they eventually combined efforts, and rolled the concepts that people liked from Merb back into Rails. It wasn't a case of just copying the code over, but it still allowed proving the ideas in the real world.
[1] https://www.crunchbase.com/organization/the-treeline-company
Fortunately, Travis did not change the Crunchbase page for Treeline. However, he did deface the Crunchbase pages for Sails, Waterline, Balderdash, and me personally (I've since reverted them).
One note: we're using Hapi by default, but koa and express4 will be supported as well. This is part of our modularity difference.
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.
If anything, this gives them the chance to start anew, equipped with the knowledge of past mistakes, to avoid making them again.
If the implementation of the Sails as a Rails-like JS framework was as bad as he says, be shouldn't use it for his next project.
A bunch of members of the community apparently had similar thoughts. As long as the idea of Rails-like JS framework isn't fundamentally flawed, they seem to be doing the logical next step: make something better.
It was only just this morning with the attention from Hacker News that we learned about the similarities between the two logos/brandmarks, and we're actively coming up with something new and different.
We'll keep the community posted on the status of the new designs here: https://github.com/trailsjs/trails/issues/47
Being open, compassionate, and transparent is a huge part of what we're hoping to do with Trails, so chatting with us directly is always an option.
We hope to see you on gitter!
All best :)
I'd hitherto not heard of tent nor seen their logo, and neither had anyone else on our team. Saying that we "stole" it is fine for sloppy internet-talk, but it imbues your statement with a level of accusatory malice that we should try to avoid.
If every other month a new thing was made, marketed, HN'd, and Twitter-culted that did basically the same thing as Nginx but had a slightly different config file format or shared-object handling mechanism or some other random detail I'd think that was also weird and somewhat superfluous.
It makes me wonder if building MVC frameworks has become so technically rote (time investment notwithstanding) that the simplicity of it has pushed them into Parkinson's Law of Triviality territory, such that everybody has their two-cents on how this weird metaprogramming trick is better than this other weird metaprogramming trick so now I can write my routes and handlers in this shape of quasi-DSL instead of that other quasi-DSL, and so then goes and makes a whole "new"... sorry... "modern" MVC framework.
How far away are we from realistically being able to replace the idiom, "bike-shedding" with, "MVC-frameworking"?
That said, I wish Trails the best-- I just think it's important to point out information that is being misrepresented.
If you have any technical issues with Sails, I would appreciate hearing about those on GitHub.
Don't get me wrong, Sails might be very good for prototyping something, but I could recommend it only if your only goal was to prototype something.
I do have quite a few other issues with sails and waterline (ORM). Waterline provided lifecycle hooks, but limited their power and had poor documentation on extending them. Same for sails core itself, it had hooks for writing modules and extensions, but no one outside of the core team knew well how to use them. As for migrations I ended up doing all of my own migrations with knex, I'd love to see knex or sequelize be the core of a new ORM, rather than a quickly cobbled together sql module.
Trails has promised something better on a lot of these fronts through modularity, I hope they deliver.
We also owe Kevin Burke from Shyp a big thank you for drawing our attention to the SEO problem in the first place. Regardless of where Shyp goes with their tech stack long term, it has been immensely helpful to learn from Kevin's experiences using the framework there. Those lessons have already impacted the direction of Sails, and will continue to influence its future development.
On the subject of documentation, I wanted to share two other resources from 2015, in case either of them might be helpful for you: The first is a free Sails course on Platzi (https://courses.platzi.com/courses/develop-apps-sails-js/). It covers best practices for authentication, blueprints vs. custom actions, and multi-instance deployment to Heroku, and contains some great Q&A. The second is "Sails.js in Action" (https://www.manning.com/books/sails-js-in-action), a Manning book about Sails written by Irl Nathan (creator of Sailscasts) and myself. It is set to be published this Spring.
Finally re: the next generation of Sailscasts-- I don't want to speak for Irl there, but I should point out that there are 6 episodes of the second series of tutorials available (https://github.com/irlnathan/activityoverlord20). You can also see the final example app that Irl and I worked on together which includes a reference implementation of present/idle/away/offline status, user login, and chat here: https://github.com/balderdashy/activity-overlord-2-preview
A newer framework from the same people has at least one thing going for them: they aren't likely to make the same mistakes.
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.
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!
[0]: https://courses.platzi.com/courses/develop-apps-sails-js/
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.
Other issues faced by myself and colleagues more experienced than me include callback hell, race conditions, NPM errors and debugging code (in hindsight, something like node-inspector would have come in handy [1]).
Why Elixir? Well, for me OTP makes writing async code much easier. Message passing between GenServers or other processes is effortless. Fault-tolerance is built into the platform, as processes can be supervised and respawned when they die. It is based on Erlang, released 30 years ago and used by many large companies and projects [2]. Also, writing it makes me genuinely happy. :)
I would consider Ruby mostly because I've had my hands in Rails apps and can make my way around them. I've also been blown away by many brilliant people I've met and worked with in the Ruby community.
[1] https://github.com/node-inspector/node-inspector
[2] https://en.wikipedia.org/wiki/Erlang_(programming_language)#...
Many past NodeJS stories/use-cases from the big name companies like LinkedIN, eBay, Wal-mart seemed to use NodeJS as a front-end server. The back-end code is still something else (or perhaps even legacy code). I know someone who works for another big name company that uses NodeJS for their new project doing exactly this as well: a front-end server that communicates with multiple/many services behind the scenes. Those services are written in Java/C#/C++.
Meanwhile, a few other NodeJS based commercial apps (e.g. Trello) does not look too complicated when they begin the project...
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.
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.
Modules is not a big problem since there are lots of node modules out there.
One could even say, why use express when meteor has a bigger community? They have modules, etc.
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-...
You could just as well ask "If Earth, Wind and Fire [2] are obsolete, what replaces them?"
There's more to modern chemistry than Earth, Wind and Electricity.
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.
Again, we seem to define these terms differently. I think if you told the hundreds of Sails contributors that they aren't actually contributors because you haven't given them write access, they would feel rather insulted by that.
> But please realize that this fork is not about technical issues
It's true that I think you're a lying scumbag, but I need a software stack that I can build my business on for the next 2-5 years. Sails.js is obsolete, and these issues stemming from your poor technical competence and community management are thoroughly documented on the internet.