HN user
Version 2 of Trails was released a few days ago: https://github.com/trailsjs/trails/releases/tag/2.0
We continue to build on the success of Trails v1, and continue our bi-annual release cycle to coincide with the Node.js release cycle. v3 will be released in April 2017 with a number of further improvements, including first-class support for GraphQL.
Thanks everyone who has contributed to making Trails a success!
Uses GraphiQL (https://github.com/graphql/graphiql) and faker.js (https://github.com/marak/Faker.js/) to auto-generate documentation and data.
Source code is here: https://github.com/langateam/graphiql.io
That was never the main design consideration of Git, but you nonetheless can make commits and branches when the server is down. Go try it.
For anyone who's interested, the github repo: https://github.com/trailsjs/trails
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.
I added them as products to the "Balderdash" company. I think we have different definitions of "deface".
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.
re stock market: A common (and expensive) fallacy of beginners who think they can beat the market with clever technical tricks is analyzing all of the publicly-traded companies' history and divining patterns in trading and such. This ignores, of course, the countless companies that have gone out of business completely or have otherwise been de-listed from the exchanges.
In analyzing these trends, you're biased by looking only at the companies that have done well enough to be on the current list. In this way it's particularly insidious, because you're omitting the very data that might save you from betting on a company that might be delisted.
Yep, good idea. I've produced a number of Sails tutorials and videos as well :) We will be doing a similar series for Trails.
They haven't announced it yet, but it'll be on the 13th at the Miami node.js meetup: http://www.meetup.com/Miami-node-js-Meetup/
They are still working on Treeline full-time as far as I know, and for the foreseeable future.
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.
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.
I'm doing that now :) We hadn't anticipated this much press before our Jan 8 release, so we're caught off-balance a bit. Thanks.
All --
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!
He owned some of the assets, still, including the github org. Even though we negotiated an agreement, and were operating the company under the assumptions of that agreement, McNeil refused to sign it at the last minute and spent the past two months clawing everything back that he could. We still own the Balderdash LinkedIn page and npm account, for example.
He refuses to speak with me directly, so there's no resolution to this yet. Nor do we really understand why he decided on this course of action at all. I hope to bring things back to some equilibrium, but one permanent change is that we are no longer supporting Sails, and are directing all our efforts toward developing Trails.
The maintained-ness of Sails is really a separate issue from the ceo-schism drama. There are plenty of other literature which discuss the technical deficits of Sails, and the incredible amount of work it needs merely to be viable as an enterprise framework. That it relies on EOL'd dependencies, and has no plans to upgrade them, is an example.
This is clickbait. Why is it on hackernews?
Your assessment is perfectly logical based on the information you have available, and also mostly wrong.
First, I'm not 22, and our COO ran the largest jQuery cobsulting firm (appendTo) for 5 years. Second, McNeil did not hire us, we purchased the company; McNeil has no ownership in the "new" Balderdash. Your educated guesses about hitting metrics and so forth don't apply to anything here.
Mike McNeil needs control of Sails.js because he promised it to his VC investors behind treeline. We did not know this when we entered into the acquisition of Balderdash, and that's not what we signed up for. Since we were lied to for nearly a year, we are pivoting the company and our open-source efforts toward other things. Trails is one of those things.
Interestingly, even though the node.js community is growing quickly and has a lot of great tools, I think your options are mainly Sails.js and Meteor.
Meteor, imho, focuses much more efforts around building shiny things to convincing new developers to try it out. It has gained a reputation of being a great framework for writing hello world in 60 seconds, but not for building real business applications. Sails is a great tool, but unfortunately is dying, as evidenced by the attitude of the creators (who have moved on to work on other things), and the multiple articles on hackernews and elsewhere discussing whether it is dying. That answer, obviously, is yes.
It is for these reasons that we (several of the core Sails.js maintainers) decided to invest in building a new framework, where we could offer a Sails-like development experience using modern node.js tools and design practices. If anyone is interested in working with us, we'd be happy to talk with you: https://github.com/trailsjs/trails.
Personal or not, our entire company is devoted to making Trails the best damn backend framework for node. We don't distract ourselves with VC-funded side projects, and we don't have a automated bot that closes everyone's issues (see: SailsBot).
Our company lives off consulting around the open-source tools we build and support. That's it.
We've started a new company to support the development of Trails. I don't want to go into the gossip of why things fell apart with McNeil and Treeline, but suffice it to say that we are no longer involved in the development or maintenance of Sails.
Trails will be the replacement for Sails. Modern, maintained, open, and community-run.
FWIW, Trails.js is based on hapi, and we will be adding Sequelize support after 1.0-beta is released in February.
If you only knew how much work needs to be done on Sails.js, you'd understand how inadequate 10 commits per month is :)
It's a parked domain that I own :) We're just recently pulling the branding and docs for trails together. We'll have a website hosted there soon.
FYI, Another HN post linked to the same thread a few days ago: https://news.ycombinator.com/item?id=10755557
FYI, Sails is being replaced with Trails: https://github.com/trailsjs/trails
I wrote the comment that OP linked to. IMHO, Sails is dying, which is why many of the project maintainers have started building a successor: https://github.com/trailsjs/trails. Yes it rhymes, no it's not a fork. It's a modern re-write with modern tools and ES6, built around similar conventions.
As I mentioned in another comment, the smaller the system you're building, the less importance your tools have to the success of the project.
Right; if you're building a large system, you'll want to structure your design around a set of common patterns. Just writing a ton of hapi/express/koa routes works only up to a point, past which the application's complexity becomes a hindrance to future progress. As with any system.
If you're building a website for your cat, then sure, the tools you use don't really matter.