mikermcneil

Built in support for WHERE subqueries, on the other hand, is on our roadmap. Currently working to finish core MSSQL support first though. Hope that helps!

On top of that, developers are forced to accept a prompt on the terminal the first time they lift an empty new app indicating that they understand this. The only way to make the prompt go away permanently is to hard-code configuration, indicating that you understand what automigrations are designed to do.

In fact, just to be safe and prevent accidents, automigrations are forcefully disabled in production mode.

In other words, to get your production/staging app into a state where this criticism is relevant, you have to ignore console warnings, skip reading the documentation, and go out of your way to trick the framework into thinking you’re running your app in development mode.

I won’t beat a dead horse re other points in that 3-year-old blog post, except to say that, 3 years ago, some of them had merit. Those have been addressed in the Sails 1.0 release.

And `await` is so much easier and safer than callbacks in userland code! Really excited about Node.js in 2018, now that `await` is supported in the LTS release. Callback hell is finally dead.

(Diff showing a refactor of an example app from traditional callbacks to async/await: https://github.com/mikermcneil/chatkin/pull/4/files)

@maryrosecook I'm glad this post showed up in our Slack feed- really cool topic! As I'm sure you've noticed from the volume, variety, and impressive comments in this thread, improving approachability/usability for software development is an exciting (albeit broad) effort, and there is a lot of amazing work underway. In the area of declarative programming specifically, there's a lot still to do, but as a community we're getting really close. That said, there is far too much work to do here for any one team to do it by themselves.

To be successful, or at least to expedite the process of democratizing software development, I believe we need to establish a common set of semantics for describing _what software is_. And the first step towards that is deconstructing functions-- or perhaps more accurately: "subroutines".

The rest of the Sails.js core team and I have been working on this problem for quite some time now, primarily as a reaction to having to build plugin system after plugin system in Sails as the framework's user base grew, and getting frustrated with every plugin system being a little bit different. After we had our first working prototype of the tech that would become Treeline, we extrapolated and open-sourced the machine specification and related utilities as a way of exposing building blocks for other devs to reuse for their own projects.

To add a little background, machines are stateless building blocks; nothing fancy. They're more or less equivalent to asynchronous functions in JavaScript, just highly specified. In particular, machines encapsulate definitions of their inputs, their exits, and whether they are "cacheable", just "idempotent", or neither (and therefore have side effects). Machines are oftentimes implemented as JavaScript functions-- although part of the project's philosophy is that what's important is the _usage_, not the implementation.

From the perspective of a traditional "intro to programming", an example of a machine is `moveTurtleDown()`: https://gist.github.com/mikermcneil/864b930a67b0d00d3d8b

As a more practical example, here's the documentation for a handful of machines related to string manipulation: http://node-machine.org/machinepack-strings (To try any of them out, just copy and paste the generated sample code into e.g. a Tonic sandbox: https://tonicdev.com/npm/machinepack-strings)

Each of a machine's expected inputs may be required or optional (with a potential default value) and declare a type schema. Each of its exits may optionally declare a return value, and if so declare a type schema for it. In addition, machines have strict conventions for meta properties (e.g. the machine `description`, which summarizes the machine's behavior when run, is ~80 characters or less of English, written in the imperative mood and in sentence case with ending punctuation)

This can be used to generate documentation, code for interactive form elements, or in the case of the default machine runner, runtime type validations.

But most important of all, once a piece of code is written to the machine spec and open-sourced, it can be used by any tool or platform which consumes that spec (think USB).

As an example, in Treeline we use machines as draggable/droppable components that you can compose into what we call a "circuit"; which can _itself_ be used as the implementation of another "composite" machine with its own inputs and exits (vs. an "analog" machine; i.e. a machine implemented with JavaScript code). We are planning to publish the circuit spec and related tooling for composite machines later this year. In the mean time, the analog machine spec is stable and ready to use. Around 500 MIT-licensed machines are available today on NPM, with generated documentation hosted on the Node Machine registry.

Hopefully that was a helpful first look- if I can help explain further or if you'd like to discuss the project roadmap, just hit me up on Twitter. It's really awesome to see so much new interest and progress in this tech, and particularly in the context of education. Excited to see where you go with CodeLauren!

As for the future of Express: I've only had the opportunity to get together with Doug in person once, but we've talked about this a few times in the past. I can guarantee you the last thing he wants is drama, so I'll leave the ball completely in his court there.

I will say this though: keep an eye on Doug's federated projects (jshttp and Pillar). Whether or not the various pieces are released as Express 5 or not, the _code base_ is still improving and becoming increasingly standardized, regardless of the monicker. More on that: https://github.com/balderdashy/sails/pull/3235#issuecomment-...

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

^^ after spending several man years of effort on the subject, that's the inevitable boundary in ORM development, IMHO. It was this that made me realize that we needed to be focused on providing a better, cleaner way to allow running custom queries using a declarative, database-agnostic syntax, rather than focusing on implementing even-deeper support for xD/A queries.

Also I don't mean to nitpick, but I'm hearing a lot of negativity towards Waterline from a couple of the commenters in this thread, and I'm not clear on how it lines up with specific, actionable criticism that I or the rest of the core team can do anything about. I get that having to use a framework or stack for work when you aren't excited about it is horrible (it was originally how I felt about Grails and Hibernate when I was using them every day in 2011).

But I think it's important to keep in mind that this is always "compared to what". The Java ecosystem has had years to develop tools for working with data, and it certainly still provides more mature utilities out of the box than you're going to get as someone new to the Node world, even today. But I firmly believe in the power and flexibility of JavaScript-- not because it's a good language or anything-- but because we all had to learn it to do front-end development in the browser. And so will the next generation of developers.

Whether we like it or not, Node.js is here to stay. And for me, that's a tremendously exciting thought. A future with the world sharing a common programming language is a goal worth fighting for. It's a future that dramatically lowers the barrier to entry to full stack web development, and vastly expands the pool of people willing and able to contribute to free and open-source technology.

Hang in there :)

I posted a few important clarifications here in the original issue: https://github.com/balderdashy/sails/issues/3429#issuecommen...

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.

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).

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.

Please leave me and my team alone.

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.