update as of Aug 2021: the webpacker-less native ES6 module imports way of handling JavaScript is going to be the default in the future Rails versions.oh and by the way, DHH nowadays explores native ES6 modules which could allow ditching webpacker and returning to Sprockets for handling JavaScript again.and finally Turbo which should become a part of Rails 7 (late 2020),.after being in beta for 3 years, Sprockets 4 was released, with support for ES6 and source maps in the asset pipeline (2019), to serve people still hesitant with webpack,.CoffeeScript, although still soft-supported via a gem, is discouraged in favor of vanilla ES6 JavaScript or Typescript compiled via webpack (~2018),.the Stimulus JS framework was released (2018),.Rails 5.1 also removed jQuery from default dependencies (2017).Rails 5.1 optionally adopted the webpack bundler and the yarn package manager (2017), the two became the preferred way of handling JavaScript in Rails,.Rails 5 came with a major and largely incompatible rewrite of Turbolinks (Turbolinks 5), the previous versions of which were renamed to Turbolinks Classic (2016),.since Rails 4, the Turbolinks library has been included but had a bunch of problems at that time (2013), so.there were Server-generated JavaScript Responses (SJR) allowing the server to update pages via JavaScript (~2011),.there was Unobtrusive JavaScript to replace the inline style it was pushed further by the jquery-ujs library (~2010), later superseded by the somewhat compatible Rails UJS (2016),. Rails 3.1 also brought CoffeeScript as a new and encouraged way of ”writing JavaScript“ (~2011),.and in Rails 3.1, it was replaced by jQuery (~2011),.there was the Prototype library since who knows when but it was phased out gradually (~2010),.there was the old and rusty inline vanilla JavaScript since forever,.Let’s just run through some of the options for working with JavaScript that we had in our pretty much standard Rails project during the course of its existence, i.e. Over the years, the ”official“ support and default conventions for building reactive JavaScript-enabled pages in Rails took many different forms. Most people love reactive pages and we do, too! So, in the end, still a lot of JavaScript managed to get into our codebase. Still, there's always been a kingdom where JavaScript absolutely ruled and that was page reactivity. That’s why we have always been cautious about bringing too much JavaScript to the project, especially for things that could be done in other ways. In other words, for a small Rails team, long-term management of complex JavaScript can be very difficult. To be clear, we do like JavaScript, it’s a fine language, especially since ES6, but in our opinion its strengths stand out and are sustainable only if you have enough sufficiently specialized JavaScript devs in a team. The road to legacy JavaScript in a long-time Rails projectĪfter all the years that we watched the JavaScript community boost its ecosystem to tremendous heights and after trying (and often failing) to keep up with the pace of language enhancements, new frameworks and build systems, this intended simplicity of Turbo is a very welcome turnaround. Let’s take a look if Turbo can be used in a long-developed project with a lot of old JavaScript code, too (spoiler: with a little tweak, it very much can!). Turbo also seems very easy to use, it just ”invites“ you to try and play with your pages. One of its main appeals is that it helps you create highly reactive web pages in Rails while having to write almost no custom JavaScript. When Hotwire Turbo got released around Christmas 2020, it was exciting news for many of us.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |