The Front-End Doesn’t Need to Be Built at All! The Creator of Ruby on Rails Makes Another Controversial Remarks

At the recent Rails World conference, DHH (David Heinemeier Hansson), the father of Ruby on Rails and co-founder and chief technology officer of 37signals, expressed his opinion that the fastest packaging tool is No Build. With HTTP/2 and native browser support for ES Modules, the front end doesn’t need to be built at all.

The Complexity Is Already Too High

Certainly! Here’s the corrected version with improved punctuation:

“We’re building everything, everything, everything,” DHH said. Currently, there are all kinds of exciting new frameworks and libraries emerging on the market. “There are so many new things, and we may have to rely on suggestions from AI to figure out how to deal with them.”

According to DHH, people seem to be getting more and more tools to create slightly better new versions, but investment is skyrocketing. This is not the right direction, nor is it an ideal development state.

DHH cited his experience in developing Ruby on Rails as an example. The team’s initial project was the BaseCamp framework, which took about six months and consisted of only one developer and two part-time designers. Ultimately, BaseCamp built a great business, generating hundreds of millions of dollars in revenue over the years. “If we were able to do it in 2003, 2004, we should be able to do more in 2023.”

As for the reason why companies take a long time to make some improvements, DHH believes that one of the important points is that in an era of low productivity, those companies that achieve early success set the standard, and others find it difficult to make substantive changes even when they realize they need something a little different: Either the effect is not as good as similar solutions from major manufacturers, or it does not have the same scalability.

According to a former Twitter employee, they decided to leave Rails because the previous architecture was not well designed, so they decided to move to Java microservices, which they thought were better at the time. But for a long time, there was no progress in the work. . They completed the project, hired thousands more people, but made no progress. Twitter’s example is basically the norm in the dark ages of productivity, where people think the work is progressing, but the incremental gains are extremely limited.By the way, Airbnb has a similar situation and it has become a trend.There are many similar problems caused by JavaScript frameworks, and they have even begun to slow down the development of the entire industry. ” DHH discussed using Twitter as an example.

DHH also mentioned that the problem of technology stack fragmentation has also caused problems for developers in the past 10 to 15 years. Architects want to solve problems they think they can solve, but not necessarily problems that really matter. So what everyone needs to focus on is what can be done that could not be done before, and everyone should strive to become a full-stack developer.

All in all, DHH believes that complexity has been stacked too high over the past 10 to 15 years and it is time to make simplicity the new goal.

How to Achieve “No Build”

As far as the front-end field is concerned, to some extent, it has entered an “infinite loop” — although it has also made some substantial progress and changed the basic expectations of developing web applications today, keeping up with trends is becoming increasingly difficult.

For the simplification of the front end, DHH proposed the concept of “no construction.” “As long as there is construction, the speed can only be increased. If there is no construction at all, won’t the speed end?”

“The state-of-the-art (packaging) technology is no longer about finding more complex ways to build JavaScript or CSS because the front end doesn’t need to be built at all. You can now rely on HTTP/2 and universal support for import maps to avoid packaging,” DHH said.

Import map allows developers to manage modules directly on the page without packaging and building. “Import map is a big adventure in Rail 7.” DHH said that with HTTP/2, the import map forms a loading waterfall flow, allowing all content to be loaded at the same time through a series of independent scripts, without having to split JS into individual packages. Developers can use esBuild more easily and smoothly, without even needing Bun’s assistance.

“No Build” also has some other wonderful features. For example, users can directly view the source on any website. The content does not involve any source mapping or any bundling. They are just the files written by the developer, a compiled pure JS file is unnecessary. Everything is delivered directly, without being built, and rendered directly on the browser side.

For an extremely complex and interactive product like Gmail, DHH believes that HAML can solve it. “HAML was created for this, where we can write pure JS code without any builds. That’s what I’m really excited about, and it’s the main way we develop right now.”

The idea of no builds is rapidly gaining popularity and has now made its way into CSS, with the popular CSS nesting feature. All browsers now support CSS compilation, and all browsers support custom properties, i.e. variables.

DHH revealed that these two features are now being used in the development of new applications by 37 Signals: no need to build JS code and no need to build CSS. “We had previously considered using nesting and variables to sidestep construction. It turned out that no construction was not only possible but extremely significant, and it took us about ten years to crack the complexity.”

DHH says the vast majority of static sites don’t require fancy build pipelines. Server Side Includes (SSI) are seriously underrated. He proposed that a Jekyll site could be converted to SSI. “Once I converted my static sites to SSI, I streamlined these into a new tool that made them simple. Has a nifty stone age technology that automatically pushes updates in 5 seconds, just give it a small virtual machine and it shouldn’t cost you more than $5 per month.”

DHH also said that in the past year and a half, 37 Signals has been moving to Propshaft, a new library used to provide asset pipelines without compilation on the Rails side. It has only two basic functions: to provide a load path for all assets, so that gems and other assets can be accessed anywhere in any view, and to provide summary tags to ensure a good long-term dynamic cache.

On Twitter, DHH also showed off the performance of the company’s main website, saying that the JavaScript code running on HEY’s main application was not built. “I think we did a great job with No Build, import map, and about 100 separate JS files! We send 500kb of uncompressed JS, and Gmail sends 10mb!”

Is It Really Useful, or Is It Just a Gimmick?

Regarding the “No Build” concept proposed by DHH, Vercel CTO Malte Ubl said on Twitter that they have tried it, but the result is that it does not work. Because in HTTP2, the overhead per request is still very high, and there are concurrency limits, in addition to waterfall streaming and inefficient compression. Currently, “packaging” is impossible to bypass for high-performance websites.

DHH disagrees with Malte Ubl’s assertion that it “doesn’t work.” “That’s the weird thing about technology discussions,” he said. Even if there are examples of projects that have proven to be able to accomplish large-scale tasks (like Rails for Shopify), people will claim that it does not scale. Or if you have used a certain method successfully for many years (such as no build JS for the HEY website), some people will say that this method “doesn’t work.”

Others think this is just a gimmick. Twitter user “Viking” said that since removing TypeScript, DHH has become more and more aggressive.

Developer Nander said, “Build time is not important; what is important is FCP (First Contentful Paint, the time from the beginning of loading to the time any part of the page content is rendered on the screen). The time of import map is no faster than RSC (build step) and minimize bundle (build step) on the same server.”

“Chrome removes the multiplexing of HTTP/2, which is no more efficient than bundling. HTTP/3 has solved this problem and may prove that bundling is a thing of the past. But as far as I know, no one has tried an HTTP/3 multiplexed esm server. Node, Deno, and Bun don’t even support HTTP/3 yet,” Joe Pea said.

Some developers pointed out that not packaging equals exposing development details to users, and browser native support does not mean efficient. The build is fast, but if the runtime is slow, is it still cost-effective? An important milestone in front-end engineering is the introduction of the build step, which separates the development experience from the user experience. In particular, the user experience of hundreds of different versions and different browsers is completely separated. This truly liberates developers.

There are developers who like this idea. Rails developer Niklas Häusele says, “I like the ‘No Build’ approach to local development. Refreshing without waiting is the ultimate in productivity. I even removed tailwindcss-rails and replaced it with tailwind CDN to avoid having to run anything locally. This would be an interesting default for the tailwindcss-rails gem.”

What are your thoughts on DHH’s “no build” philosophy?

Reference Links：

Stackademic

Thank you for reading until the end. Before you go:

Please consider clapping and following the writer! 👏
Follow us on Twitter(X), LinkedIn, and YouTube.
Visit Stackademic.com to find out more about how we are democratizing free programming education around the world.