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.
Hopefully. We've actually seen some (mostly superficial) activity in Sails recently, which is surprising and encouraging.
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.
> 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.
Certainly you're not alleging that I created that account to write that comment? Not only do I not have time for that kind of dishonesty, Sails was created while I was running one of those "kind of consulting shops".
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]
We are working on Treeline, a tool that compiles Sails.js apps. Our backend is running on Sails.js in production.
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).
>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.
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.
100% agree with you. I don't agree with the comment you replied to, but it's _not_ a good sign that they stole another project's logo. https://tent.io/
Hi bnb, it hurts to see the word "stole" and judgement passed so hastily, so I thought I'd take a quick second to reply.
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've been in contact with the owner of tent, and are responding appropriately. Our logo unfortunately does bear a strong resemblance to theirs, which our designers are working to resolve.
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.
Can I dismiss it because it's like the 50th "modern MVC framework" to be made for Node.js? Are all the other ones so hopelessly broken that it required making an entirely new one?
Opinion? Both sentences were questions. The first included a hyperbolic approximation (i.e. "50th") and the second included a legitimate direct question that infers an indirect question about the weird pace of churn and factionalization that seems to infect the Node.js community more than any other community.
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"?
I'm just saying if you have a criticism share it. If your problem is being an nth iteration then that's not really comment worthy. Sure the node ecosystem has an abundance of modules and frameworks. I don't consider it harmful and it seems the developer mindshare sorts through these "problems" with ease.
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.
Once you start shipping to production you care far less about "speed of development" and "prototyping things" and more about "does this actually work".
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.
Fair enough, though I do have some experience with shipping to production.
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.
Lack of documentation has probably been my biggest gripe with Sails. The documentation on their website was broken for almost a year ("but it's on github! Go find it there"). They had a Getting Started "Sailscasts" series that was helpful, and then they released the beginning of the V2 videos (using a SPA w/ Angular), but only got three videos in.
Thanks for following up, Clay. Sorry sailsjs.org caused trouble for you last year. You're right-- fixing SEO permalinks in our docs (i.e. converting sailsjs.org from an SPA to a site w/ server-rendered views) was a pretty slow and involved process. This was due in part to the fact that we switched to deeply-nested navigation in the docs, but also because of the sheer number of old links we had to maintain from two different past versions of the website. We weren't able to preserve them all, but we did our best to maintain the functionality of as many legacy hashbang (`#!`) and Angular-style (`/#/`) links as we could. I'm glad to hear the doc links are working for you now.
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
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.
For me, it's personal preference. Node.js is used and loved by many, but to me it's just an asynchronous event loop running on a single threaded process with a JavaScript API. I've written performant Node.js code and maybe for smaller web services it's great. But for a backend server, I worry about human error in large, evolving projects (especially when it comes time to scale).
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.
I'm with you on this one (except the Elixir part, never tried, can't comment).
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...
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.
I just found it easier to work with. Some might find express easier, but that is just my opinion. There are also companies using hapi in production. Walmart used it and worked on black friday.
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.
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]
When I hear the Facebook-React people talk about "MVC", it seems like their experience of the term is from Native-UI frameworks, especially those with active Views that call themselves "MVC".
Then we have "Javascript MVC" frameworks like Angular, which have "bindings" and this makes them MVC.
Then I think about the Server-side web programmers (i.e. Rails) which are also "MVC" that render the whole response for a request.. the view is often just a template. This is also "MVC".
Basically the term has completely lost it's meaning at this point.. It's simply a pejorative term now, because we don't take the time to name/reveal the particular things we don't like about certain frameworks, we just call them MVC.
It's not just about replacing the controller, which nobody understands or agrees on [1] -- it's about getting away from the idea that you can oversimplify user interface architecture down to a holy trinity of just three elemental concepts.
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.
With Cycle MVI can be just a guide for getting started. (More pejoratively, a crutch.) I regularly find the intent()-model() interface getting too verbose and boilerplatey so I just munge the two pure functions together into one. So far it's made sense to keep view() separate, however.
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.
> Travis is the _only_ former Sails contributor (i.e. someone with actual write access to our repos)
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.
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.