Basecamp Releases Hotwire for Building Web Applications Using 'HTML Over the Wire' (hotwire.dev) 60
Basecamp's David Heinemeier Hansson (the creator of Ruby on Rails) announced on Twitter this week that "all the tricks and tooling we used to build the front-end for Hey.com" have now been released as Hotwire (also known as New Magic), "an alternative approach to building modern web applications without using much JavaScript by sending HTML instead of JSON over the wire."
This includes our brand-new Turbo framework...a set of complimentary techniques for speeding up page changes and form submissions, dividing complex pages into components, and stream partial page updates over WebSocket. All without writing any JavaScript at all...
Hotwire's web page argues HTML over the wire "makes for fast first-load pages, keeps template rendering on the server, and allows for a simpler, more productive development experience in any programming language, without sacrificing any of the speed or responsiveness associated with a traditional single-page application." On Twitter, Hansson called it "a refinement of years of research, experimentation, and SHIPPING HTML AT THE CENTER. It's been a revelation for us. Both for the web, and for our native apps." He shared a 13-minute video demonstration — then added a thoughtful comment about the state of web development today.
"Really curious to continue pushing the ECMAScript 6 + ES Modules approach in the browser. This isn't strictly related to Hotwire, but it's part of deconstructing the overly complicated mess we've all made of frontend development. One brick at the time!"
Hotwire's web page argues HTML over the wire "makes for fast first-load pages, keeps template rendering on the server, and allows for a simpler, more productive development experience in any programming language, without sacrificing any of the speed or responsiveness associated with a traditional single-page application." On Twitter, Hansson called it "a refinement of years of research, experimentation, and SHIPPING HTML AT THE CENTER. It's been a revelation for us. Both for the web, and for our native apps." He shared a 13-minute video demonstration — then added a thoughtful comment about the state of web development today.
"Really curious to continue pushing the ECMAScript 6 + ES Modules approach in the browser. This isn't strictly related to Hotwire, but it's part of deconstructing the overly complicated mess we've all made of frontend development. One brick at the time!"
Neat idea! (Score:5, Funny)
You send html as response to an http request!
Re: (Score:2)
You completely broke my sarcasm meter. I hope you're happy.
Re: (Score:1)
Call it the "Wab", no, how about "Wub"!
Like iframe but more general (Score:2)
Fetching HTML fragments and setting elements' innerHTML in script indeed resembles HTML's <iframe> in a way. It also does some things that <iframe> can't.
As someone who has no idea what this is about (Score:3)
My question is: how will this help advertisers push unwanted content my way, website operators track me without my consent and steal my personal data, or malware get sent to my browser?
Or conversely, how will this help the above issues?
I'm reading less Javascript, meaning less stuff you can block, possibly.
Re:As someone who has no idea what this is about (Score:4, Informative)
Unsolicited, uncontrolled HTML injection into a web page has long been considered bad practice for the reasons you mention, plus the capability to just break the document.
Re: (Score:2)
Re: (Score:1)
It sounds like something that was written by a person with a management degree, given all the buzzwords in the summary. (C programmers don't tend to speak this like).
Re: (Score:2)
Also - unrelated - nobody codes websites in C. Hmm... I wonder if there's a connection.
Re: (Score:2)
Also - unrelated - nobody codes websites in C. Hmm... I wonder if there's a connection.
Yes, when your browser successfully contacts the server, there is a connection. :-)
Re: As someone who has no idea what this is about (Score:2)
Well, web-2.0 nutters do. Like Ruby-on-Rails degekopers, WhatWG members, recent browser makers, and anyone who thinks a webdev is a programmer.
(Disclaimer: I was a webdev myself, wrote webapps since 1998, and wrote stuff like RoR myself. I learned that is was all pointless, with the ultimate end result of re-inventing of the wheel, with more platform ontop of platform, an dismissed it, out of coincidence, right when it started to become big.)
Re: (Score:2)
I'm there. I don't need or want huge frameworks to do the job of HTML, CSS, and Javascript that I could more easily write myself. Thus, I've been very slow to ramp up to learning things like Angular, Vue, React, and their ilk.
But, given that recruiters reject people out of hand if they don't claim 10 years experience with the latest Javascript framework-du-jour, how does a person who's evolved past the need for those kinds of frameworks become and/or remain gainfully employed?
Worry about WASM instead. (Score:4, Informative)
This won't affect you badly, unless you are on a slow connection with a fast device.
Your browser has no obligation to render any HTML or download any urls embedded therein. Ad blockers will work fine and have a much easier time toom
What I would be way more concerned about, is compiled obfuscated WebAssembly files that contain both things essential to the site, and advertisement/tracking code.
Because no ad blocker will disassmble, parse, and process those anytime soon.
Re: (Score:2)
It has nothing to do with anything you mentioned. It's about the arrangement of web developer tools. Like keeping a screwdriver in the drawer under your workbench instead of on the pegboard behind it.
Re: (Score:2)
Thanks. Just what I needed to know.
Re: (Score:2)
I'm reading less Javascript, meaning less stuff you can block, possibly.
If you're blindly blocking code based on its language rather than its content or purpose then you're doing something very wrong.
Markup, style, and behavior (Score:2)
The three purposes are markup, style, and behavior. Static documents have only markup and style. Web applications have all three. There's a third category of documents that would have been static but for the intrusive behaviors of modern adtech. As I understand it, people who object to "JavaScript" are really objecting to server-specified behavior in the browser, and they do so because they believe that this third category has poisoned the well.
Re: (Score:2)
Which speaks to my point. The goal isn't blocking javascript it's blocking specific application of it. That is language agnostic. Javascript isn't the only thing used for tracking users on the web, and it isn't the only thing an even remotely competent content filter blocks.
Tapestry circa 2005? (Score:4, Informative)
Headline - Ruby on Rails creator reinvents Tapestry [apache.org], using websockets instead of xmlhttprequest.
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
Sure, now you're tied to Ruby instead - personally, I don't see that as a win despite Java's weight. It's not like there's a wealth of cross-language backend frameworks out there - graphql, xslt, and ...? But the story wasn't about the launch of another ruby-based backend framework. It was about the somehow 'groundbreaking' idea that you can send a response to the client that is already rendered into html in the server ad then injected into the requesting document by the client - and that is hardly some k
Re: (Score:2)
Re: (Score:2)
How are you "tied to Ruby"?
Of course you're not tied to Ruby, but the video is truly awful at conveying this. Someone got triggered, made a poor comparison, got modded up, and the groupthink kicked in.
Basecamp (Score:3)
I think they spelled "B.S. Camp" incorrectly.
Re: Basecamp (Score:2)
I think "Ruby on Rails" already told us everything we needed to know.
You can thank Google for that mess. (Score:3)
It doesn't serve anyone but their browser monopolism.
Of course if the actual site developers wouldn't run after each new stupid feature and use it, often even before it's standardized...
I, for one, as an ex webdev, have given up on the "platform". I'm too old to be wooed by something like that.
I'm writing regular applications, and deploy them the regular application way, as a server service with its own protocol and port (no HTTP), and if necessary, cross-compiled to "legacy platforms" (wasm+html5, the desktop, other toys)
What client-side stack isn't legacy? (Score:2)
I'm writing regular applications, and deploy them the regular application way, as a server service with its own protocol and port (no HTTP), and if necessary, cross-compiled to "legacy platforms" (wasm+html5, the desktop, other toys)
Unless there's something fundamental that I'm missing, what you call "legacy platforms" will dominate the client side for a fairly long time.
Neat Idea, but... (Score:4, Interesting)
The approach makes some sense when the only client you're shipping to can render HTML. I've found that this is rarely the case.
JSON and YAML based REST API's (i.e. the API-First approach) are successful because the data is not tightly coupled to the presentation, and can be converted easily to whatever runtime is consuming it. The end result is that you don't have to provide different server-side code paths for a CLI, Mobile, Web, or embedded client, and can treat all of them as a "client". To offer up a real modern product surface with both a web experience and other integrations, this approach is a step back to the mid-2000's. Think "Let's build a JSP/Spring hybrid app that renders both JSON and HTML". The add-on feature of "you only ship the delta of the HTML" is just an implementation detail.
Even if you add an intermediary server layer that sits between the JSON api and the browser (i.e. the Backend-only-for-frontend antipattern), all you've done is add more code that you have to maintain. Personally, I like less of that.
Re: (Score:1)
Even if you add an intermediary server layer that sits between the JSON api and the browser (i.e. the Backend-only-for-frontend antipattern), all you've done is add more code that you have to maintain. Personally, I like less of that.
I don't understand this bit but probably because I'm not a web developer. Code to render HTML from JSON still needs to sit somewhere. Why does doing it server-side result in more code overall? I'd naively imagine that it's about the same.
Re: (Score:2)
As long as one of those clients is serverside, because I don't want to run your code on my device. I will render your HTML however.
Pages that update; image maps with drag (Score:2)
Say you're rendering the HTML of a chat client. What causes your device to check for updated HTML when another user sends a message or an image to the channel/room? Remembering to press F5 every few seconds?
Say you're rendering the HTML of an online whiteboard. How do you input a drag gesture in order to add a stroke? The server-side image map as currently specified in HTML accepts only clicks, not drags. And what causes your device to check for updated HTML and/or an updated image when another user adds a
Re: (Score:2)
"OMG, what about niche webapps?" you say? I say losing those would be a small price to pay for what should be static pages instead running JS and loading a thousand libraries. But I get that in those cases I'll have to whitelist the site to use JS or not use the app. However, Twitter worked just fine with HTML only until they deprecated it two weeks ago to push people to the app. It's not usually a result on inability (look at /. with JS off), but instead a lack of desire. Unless you need one of a coup
Re: (Score:2)
Also, F5 is unnecessary because headers can trigger auto-page reloads every N milliseconds.
A chat client contains a list of the most recent messages and a form with which to compose and submit a message. Does "auto-page reloads every N milliseconds" preserve the text that you have entered into the compose form?
Re: (Score:2)
The end result is that you don't have to provide different server-side code paths for a CLI, Mobile, Web, or embedded client, and can treat all of them as a "client".
It's called CSS. HTML is the "Model". CSS is the "View". Your server is the "Controller". No JS needed. Also, not a new idea.
Re: (Score:2)
JSON and YAML based REST API's (i.e. the API-First approach) are successful because
HTTP based REST APIs suck ass. They offer no useful transaction semantics, have poor performance /w even worse interoperability and discoverability.
the data is not tightly coupled to the presentation, and can be converted easily to whatever runtime is consuming it.
Generating HTML for presentation on an HTML display does not itself communicate relevant information regarding "coupling". What is relevant is the methodology used to generate HTML.
The end result is that you don't have to provide different server-side code paths for a CLI, Mobile, Web, or embedded client, and can treat all of them as a "client".
Where the code to drive a specific presentation protocol comes from should be considered based on practical implications rather than abstract ideology. Adding yet another level of
What about embedded? (Score:3)
How would this affect web servers hosted on tiny embedded servers? I presently work on a system that tries hard to shove as much work over to the client as possible simply because there isn't enough local CPU bandwidth available to do anything more. We've found that web APIs and JSON neatly divide data from presentation, permitting the user experience to be pretty awesome to a host system having significantly less power than a Raspberry Pi.
Re: (Score:2)
Negatively.
Re: (Score:2)
Well, yes, certainly. But I was hoping to find a performance multiplier value.
My finger-in-the-wind guess is that I could easily see 10x WORSE performance, both from the user perspective and the host load perspective.
There may be edge cases where this approach could make sense for embedded systems, but I can't think of any ATM. I suspect it would take some very good CSS work, which gets us back to programming on the client.
Even if it could work well on some embedded systems, it likely would only make sens
Re: (Score:1)
We've found that web APIs and JSON neatly divide data from presentation,
You know what else neatly divides the data from the presentation? HTML and CSS. HTML is the data, CSS is the presentation. It was sometimes difficult before Grid, but now (as of what, 10 years ago?) you can reposition and re-arrange any data down to the field via Grid.
Re: (Score:2)
HTML is the data, CSS is the presentation.
What is the notification that new data has become available for display?
Re: (Score:2)
Re: (Score:2)
Hotwire is thus a DHTML framework.
Once browsers have DHTML, companies can build intrusive adtech using DHTML. Is there a way to do something with the same use cases as DHTML that is usable across all major desktop and mobile operating systems without needing case-by-case approval of each application and without allowing for intrusive adtech?
Reduces Complexity (Score:1)
What makes this valuable is it reduces complexity. Code is writing. Virtually all the cost of code is in its creation and perfecting, not its running. Anything that makes one's writing more succinct and readable is therefore a major plus.
I like the ideas here. I like them a lot. If they work as well as described you bet I'm going to give them serious consideration.
PJAX? Turbolinks? (Score:2)
an alternative approach to building modern web applications without using much JavaScript by sending HTML instead of JSON over the wire
Is that somehow related to PJAX or Turbolinks? Sounds like the third generation of the same idea to me.
Re: (Score:1)
Possibly even the fourth. I was using Brent Ashley's Remote Scripting to return HTML fragments from the server over 20 years ago. That didn't need fancy stuff like web sockets with all the overhead of parallel secure connections to manage.
I'm getting old (Score:2)
When I read the title (we oldsters are not allowed to read TFA or TFS) I thought of Buildings with wiring where you could send HTML commands to your washer/dryer to start at 5am, so that your sweatpants for the day are dry, warm and fluffy when you get up and stuff like that.
How well does this cache? (Score:3)
Ultimately the use of this or any other paradigm depends on your use case. Twitter, bestbuy.com, and your company's internal purchasing app all have different usage patterns. Extreme caching is huge for Twitter and BestBuy.com, but for a purchasing app or router configuration screen, simplicity would matter much more.
That said, I have long complained that HTML rendering is the easiest part of any page render, so moving from server side to client side like everyone did 10 years ago didn't add much, unless you have 100,000s of users and local caching became a factor. Server side rendering is really out of style, but I love it quite a bit. I love that everything loads at once. I love how fast simpler pages render and scroll in my browser. I rant about this often on slashdot, but my company has a legacy configuration app written in 2005-era technology. It's a JOY to use. It has simple table tags for layout and everything is rendered in Ruby on Rails server-side.
The joy is that I request the page and wait for the native browser's spinner to stop spinning. Once the browser says it's done, everything is done. I can load 1000 rows and it scrolls so fast I cannot believe my eyes....none of this responsive web bloat...no one cares how it looks on your iPhone. It's fast. I can do my job very quickly when I use it. Fortunately it has escaped the attention of our front-end team who will no doubt add 20 JavaScript frameworks for reasons I don't understand and they cannot explain to me, but everyone says they're best practices and I'm a dumbass because I don't know why a simple web app needs 20 JavaScript frameworks for a remedial CRUD app, but I don't like sounding like a luddite, so I give up and go back to doing my actual job, which is not critiquing modern front-end development trends.
I'll have to try out his new protocol to see how well it works. I will say that backend developers are MUCH better at their jobs than front-end ones. Every place I worked had rigorous test driven development and much higher standards of quality than the same company's front-end team. This could allow the diligent detail-oriented backend devs like me focus on quality and let the more artistic and customer-interacting front-end team focus on layout and usability. It could be a godsend for some apps.
Re: (Score:2)
They are probably trying to fluff their resume with as many buzzwords as possib
Re: (Score:2)
80s (Score:2)
The 80s called and wants its ideas back. I mean HTML responses, what a revelation. Can we please, please, create separate responses for each browser and spend a lot of time on that with each browser update? Because who needs standards when every 5 minutes someone has a better idea for how this should work?
Finally! (Score:2)
Hotwire ... This includes our brand-new Turbo framework...
A framework to generate web pages like before there were frameworks.
Use the web as a thin client? (Score:3)
...and handle presentation layer stuff on the server? Crazy. Well... it's crazy that the development world is still swinging back and forth so hard on this after 40 years.
When people implement this, they'll see old bad patterns come back. Presentation and business logic will get mixed up together in awkward, difficult-to-maintain ways. You'll get pages where the state gets complicated or out-of-sync, some stuff will be difficult to debug, and you'll wish for simpler transactions between client and server (and for the ability to re-use endpoints between different types of clients).
And then someone will save us by introducing thick clients. Then thin clients, then thin ones but with a twist, then thick ones again. And, at every generation, I have to pretend to be excited about the new game-changing paradigm.
Re: (Score:2)
I like to think of each generation as a move toward a perfect middle ground between the two methods.
Re: (Score:2)
Rails was meh and this will be meh too. (Score:2)
So we have a new web toolkit from the crew that gave us Rails. Big fat hairy deal. With some new buzzwords and oh-so-brand-new paradigm thrown in. ... I somehow can't shake the notion that somewhere, 20+ years back, something like this has already been covered either by Zope (in Python) or ArsDigita (in TCL).
However, I couldn't give a flying f*ck. The serverside web is owned by PHP, and for good reasons. The only thing I'll somewhat accept as a possible alternative is something that also does JS on the serv