When building a web app, thereās a whole lot of factors to consider, including the server-side language, the type of database youāll be using, the front-end framework to use - and, of course, how each of these pieces will be interacting with each other. Sometimes, though, you just want to bypass this mess and start building.
And by sometimes, we mean most of the time.
Reactive frameworks help solve this problem by allowing a single programmer to control the entire application stack in a tightly integrated package. The resulting app treats HTTP more dynamically, establishing two-way flows of data rather than a simple transaction of documents across the network.
Ember is one big player in the reactive framework game, providing light, powerful code on the front-end for large web applications. It quickly updates templates (based on Handlebars.js) when the underlying data changes. The focus on developers helps reactive apps feel more like writing with an API than wrestling with the server. Ember doesnāt have explicit solutions to server-side code, however, and also goes through a number of rapid iterations, which can result in difficulties for smaller, more static applications. It truly demands a large, dynamic application that has the team and flexibility to take advantage of it.
Another option is Elm. It's functional and concise. Immutability and type inference, for example, help a developer write short, fast, and maintainable code. It's reactive. With Elm, you can create interactive applications without callbacks or shared state. Finally, it's compatible with HTML, CSS, and JavaScript. Elm uses what it calls Signals. A Signal is a value that changes over time. Two examples are Mouse.position and Window.dimensions. With these abstractions, a developer does not need to manually handle events. Thus, there isn't a need to use callbacks or shared mutable memory. The benefit of this is that, because it leads to an architecture that centralizes state, it's difficult for the model to get out of sync. What's the problem with callbacks? In callback heavy frameworks, such as AJAX or Node.js, applications are passed around as callbacks. This makes them difficult to readāit forces the developer to jump around the codebaseāand difficult to maintaināchanges to seemingly unrelated functions may cause things to break. For updates, Elm uses a virtual DOM. To this, it adds purity and immutability. This combination results in fast performance. Purity means that functions will always have the same outputs given particular inputs. With the virtual DOM in Elm, if the current virtual DOM and the new virtual DOM are the sameāthat is, if they are referentially equalāthey must also be structurally equal. This is because all values in Elm are immutable.
Other reactive frameworks lend themselves to rapid development. Sails.js is a flexible and scalable MVC framework that was built primarily to support Node.js on the backend and works with various front-end frameworks on both web and native applications. Aside from being able to support various front-end frameworks, Sails uses Waterline for object-relational mapping which allows it to support sourcing data from different types of databases such as MySQL, MongoDB, Redis, etc. As it was built to support Node.js, Sails also utilizes Express for handling HTTP requests and WebSockets for real-time communication, with both remaining to be the most established Node.js modules for their use cases. Being fully written in JavaScript, this and all its other strengths places Sails in the space of a good āfiller technologyā for people who have a great deal of skill with other Javascript frameworks. Where Meteor forces a paradigm onto the entire stack, Sails permits the integration of any front-end, and any database - even if they donāt exist yet. This allows for a great deal of flexibility, but also mastery over a number of moving parts. Another strength of this framework is the ease of development, getting started is quick and RESTful APIs are surprisingly easy to create with Sailsā auto-generation capability. One downside is its relative youth over other frameworks - the code base is still growing, as well as the documentation and the developer community around it.
In the middle of the playing field are players like Meteor. Meteor allows for rapid but scalable development that is production-ready. Meteorās code is readable, light, and ideal for producing excellent apps with quickly. This comes at the cost of some flexibility; Meteor can feel monolithic and inflexible as apps become more mature. With its extensive documentation and commitment to simplicity, itās allows for full production in a single language, and with tons of ābackground magicā that allows programmers to work more efficiently. Furthermore, Meteorās pledge of simplicity allows for some programming best practices to shine through, which can be seen in its handling of database systems; where some frameworks might try to impose their own rules on the database, Meteor plays well with the already well-established ACID properties existing within database languages. For example, Meteor uses the Distributed Data Protocol, which runs over a WebSocket, to move data between different parts of the app. This allows it to deliver live updates as data changes. This means the programmer has less to worry about, but also means that Meteor isnāt trying to force properties that have already been done well.
Derby is yet another reactive framework that could perhaps be thought of as a more flexible, extensible version of Meteor. Derby handles the backend using Node.js like Meteor, but one notable difference is Meteorās abstraction away from the fundamental way Node.js writes programs (i.e., using callbacks). Typically, Node.js accepts requests for documents, but while it waits for the documents to actually load, it moves on to the next request, and will then āserveā the documents for the original request when theyāre loaded. Meteorās Fiber engine goes back to a more traditional threading model but introduces hierarchy; certain fibers can have more CPU devoted to them by the programmerās choice. This can starve the non-prioritized threads of CPU, though, and also disregards JavaScriptās asynchronous nature where Derby embraces it. It is worth noting that, while Meteorās Fiber engine uses fewer lines of code that are easier to read, debug, and modify, fibers can be used well. Depending on the type of application, Derbyās reliance on callbacks might be better, or Meteorās Fiber engine might work better for the team of developers - however, this type of tradeoff seems to be reserved for more mature business logic. Truly rapid development in early stages might be better achieved with Meteor because of its simplicity.
