Is Rails well positioned for where the web (on all devices) is going? Pal Dave Copeland asked that on Twitter. Turns out I had plenty of opinions!
- I buy into the notion that the majority of applications donāt need much special in the way of browser-side functionality. SJR, a little bit of CoffeeScript, and SCSS will do you fine.
- For the rare team building ambitious applications, an opinionated framework like Rails is probably the last thing you want. Ambitious applications, perhaps by definition, are going to cut against the grain in one or more places. An opinionated framework is only going to get in the way of the opinions that make the application ambitious in the first place.
- The web is in a weird place. I think itās a somewhat risky environment to build for browsers right now. The combinatorial explosion of devices and browsers means that youāre almost certainly giving some non-trivial class of user a suboptimal or buggy experience. Choosing where to spend your effort seems like a non-fun process.
- There isnāt a high-quality, well supported, well conceived ecosystem that currently exists for browsers. Rails and iOS both succeeded with a combination of smart conception, (mostly) excellent execution, and supportive communities or vendors. Front-end technologies are deeply splintered right now.
- I suspect thereās no opportunity for Rails to crown a winner in this space until the Cambrian explosion of JavaScript and CSS practice coalesce into something coherent that most developers can relate to and execute.
- But, if I had to wager, my money is on Rails choosing Ember as a default choice. This would happen on the trailing edge of fashion though, in the same way that jQuery didnāt become the default for Rails until long after jQuery became the go-to choice for most front-end developers.
- Even if the Rails core team could pick a winner on the leading edge of fashion, I donāt think it would work out. The Rails core team has much less experience with the front-end than the back-end. Historically, the choices have been OK (CoffeeScript turned out well, Prototype+Scriptaculous was an excellent early choice) with a recent trend towards provoking wild disagreement (e.g. CoffeeScript and Turbolinks).
- I think a lot of this comes down to Sprocketsā ability to gracefully grow to support front-end practice. It already does a pretty good job. Adding better support for browser components (e.g. Bower) would be good, as well as keeping up with SVG, web fonts and other somewhat special asset types.
If, tomorrow, I did have to build a Rails app whose web experience was crucial, Iād be as conservative as possible with my library choices. Iād stick with the oldest, boring-est, best-tested JS and CSS tools until it wasnāt feasible anymore.