24 ms·

Hotwire: HTML over the Wire

• Nijikokun 6y ago
  Sigh, this is already what modern frameworks do.
• dmitriid 6y ago
  Without reading the details, LiveView in Phoenix (Elixir) sends HTML/DOM updates only. Hotwire sounds pretty similar (and it's a good thing IMO)
• jarym 6y ago
  I won't say this is a step backwards in terms of progress but it is a step back to the way things used to be done in the early days of Ajax - albeit with a slightly more modern approach. It is appropriate for some applications and not for others. That's just my view.
  • CrazyStat 6y ago
    I'm not really a web dev, though I've built a couple small (mostly static) sites. Could you expand a bit on what makes it appropriate or not for different applications?
• mmastrac 6y ago
  What's old is new again. I recall ASP.NET had some interesting tech around this in the 2000s where it could dynamically update parts of the page. If I recall correctly, this made use of that new technology of the time called "XMLHttpRequest" (/s) which pretty much jump-started web 2.0.
  • vittore 6y ago
    good ol' ASP.NET 2.0
  • recursive 6y ago
    AjaxContentPanels or something to that effect. Those things were a nightmare. At the time, asp.net pretended to be stateful by bundling up the entire state of the page into "ViewState" and passing it back and forth client to server. Getting that to work with those panels was more work than just ajax-ing the content and injecting it with jquery. In the Microsoft-verse, this might also draw some comparisons to the more modern server-side blazor.
    • mmastrac 6y ago
      Oh yeah. I remember that ViewState could reach 100s of KBs on a page if you weren't careful. It was a huge juggling act between keeping state in your input fields vs ViewState.
    • toddwprice 6y ago
      <UpdatePanel /> see here: https://docs.microsoft.com/en-us/dotnet/api/system.web.ui.updatepanel?view=netframework-4.8 https://docs.microsoft.com/en-us/dotnet/api/system.web.ui.up... I used it 13 years ago. It was fancy.
  • axegon_ 6y ago
    My thought exactly, though I fully support that. I often rant about how the modern web is billions of layers of duck tape over duck tape and it has become an unmanageable mess of libraries, frameworks, resources, all while javascript remains the most outrageous and absurd language ever created. I'm by no means a fan of rails or ruby for that matter but I think things like these are a considerably better alternative than all the ridiculous libraries and frameworks everyone uses, which result megabytes of javascript and require corporate-grade bandwidth and at least an 8-th gen i7 and at least 8gb of memory to open. And all that to open a website which has 3 images and a contact form. I mean someone should create a package that analyzes websites and creates a minimum requirements manifest. It's good to see that there are people who are trying to bring some sanity.
    • ChrisLTD 6y ago
      Preach! Websites don’t seem all that much better to me than they did 10 years ago [^fn], so what are we gaining with all these much more complex and fragile tools? [fn]: Arguably, the web is worse with chat bots, sticky headers, and modals constantly vying for your attention.
      • craftinator 6y ago
        > Arguably, the web is worse with chat bots, sticky headers, and modals constantly vying for your attention. We can blame this on the MBA types. I've literally never heard a software engineer say "hey, let's make this pop-up after they've already been looking at the page for a minute!" or anything like it.
        • rorykoehler 6y ago
          Engineers typically aren’t tasked with increasing revenue/engagement.
          • Nextgrid 6y ago
            Unfortunately I have to disagree - if there weren't any engineers around to implement the dark patterns they wouldn't be as prevalent. Maybe this calls for an equivalent of the Hippocratic Oath but in the tech world?
  • shireboy 6y ago
    Glad I'm not the only one seeing that parallel. I'd be hesitant to use this for that reason, but maybe that's bias on my part? Just seems like you'd get stuck in a similar mess of "special" updatepanels aka hotwire frames that are trying to "save you from having to write javascript". Except it still uses javascript under the covers, so you still have whatever issues that may entail, only now it's more removed from the developer to be able to solve.
  • deleted 6y ago
    [deleted]
  • hn_throwaway_99 6y ago
    Interesting bit of history (and yes, I see the /s), XMLHttpRequest was actually invented by Microsoft in Explorer because the Outlook team needed better responsiveness for the web email client.
  • grishka 6y ago
    Is this that web framework from Microsoft that hid the transaction-orientedness of HTTP from you by letting you set server-side click listeners on buttons and generated all the code needed to glue it all together? At the time, I didn't feel good about it because it abstracted away too much, and required Windows on the server. Little did I know about all the ways people would start abusing JS in 10 years.
  • merb 6y ago
    webforms is dead, long live webforms.
  • EdwardDiego 6y ago
    Yep, was using this approach in Java server-side frameworks 12 years ago.
  • hinkley 6y ago
    jquery also had a function for doing swaps. Then there's Rails turbolinks, and now Phoenix LiveView in Elixir. I don't know if it's so much 'everything old is new again' as it is a problem of market penetration.
  • msie 6y ago
    We need something like XMLHttpRequest right now. Google should integrate Dart into Chrome.
• heidar 6y ago
  For those unaware, this is the "new magic" that dhh has been on about since HEY was in beta.
• fuball63 6y ago
  I read a little about Turbo, not sure I get it, is this like htmx? https://htmx.org/ https://htmx.org/
  • zomgwat 6y ago
    They're similar in concept but Turbo uses WebSockets and htmx is more about AJAX.
    • w_t_payne 6y ago
      I've been using HTMX to send "server push" updates over SSE ... I think it wouldn't be too hard to use websockets as well..
    • simonw 6y ago
      Turbo uses Ajax for most of its functionality too. The WebSockets bit is an optional add-on if you want to push updates from the server e.g. for notifications.
• corytheboyd 6y ago
  I get the feeling it will draw a bit of criticism from this crowd. IMO it’s fine to experiment with tech like this, but I have to wonder where sending HTML fragments over Websockets instead of HTTP falls apart. Curious to hear about the success/horror stories in a few months/years from any adopters :)
  • city41 6y ago
    I found this little thread on Twitter interesting, complaining Hey (powered by hotwire) is too slow https://twitter.com/youyuxi/status/1337851036015480843 https://twitter.com/youyuxi/status/1337851036015480843
    • petey283 6y ago
      And here's some additional followup. Minor speculation that maybe his location is what caused slowdown. https://twitter.com/swyx/status/1292825527116369922 https://twitter.com/swyx/status/1292825527116369922
      • methyl 6y ago
        That's one of the reasons SPA aren't going anywhere: trying to handle all the user microinteractions on the server is great when you leave next to it, but it falls apart when your users are spread across the world, especially if it's not western-ish world with fast internet connections.
        • vasachi 6y ago
          Huh? How does SPA help here? JSON payloads don't go faster over the wire than html.
          • jeroenhd 6y ago
            JS interacting locally can make a web page be perceived to be faster, even if there's no meaningful content yet. Humans enjoy working with systems that so _something_ as soon as they interact with them and a placeholder/spinner/animation is that exact something. Of course, you don't want any placeholders or animations to go on for too long, but it's good to know that the button you just pressed actually did something and the screen hasn't hung. Minimal JS pages often have very little direct interaction built in, so they feel blazing fast when the connection is good and the payload is small (HN is a great example) but terribly slow if your internet connection is bad and it's not masking the network delays (again, HN is a great example). The 2-5s mentioned on Twitter are something else though, perhaps the Hey app is being transferred through a saturated connection in the US or something.
• paxys 6y ago
  It's hilarious that web servers rendering HTML and sending it to the browser over a TCP connection is now "cool new tech".
  • wejick 6y ago
    It's actually not as simple as that. The simplification is too brutal and doesn't appreciate the details. It's the answer for people that sick of the weight of modern webapp, where everything need to be rendered client side.
    • sfvisser 6y ago
      Honestly, my experience is that most webapps aren’t that heavy for what they actually do. Web sites are heavyweight, serving megabytes of useless nonsense just to display an article. With a bunch of ads obviously.
  • deleted 6y ago
    [deleted]
  • ravenstine 6y ago
    I'll just take a break for 3 years until SPAs become cool again. But they won't be called SPAs anymore... they'll be called "microapps". Elixir and Rust will be "just not fast enough" and there will be a new language VM that will "promise Hyperspeed™ on Google Crystalline™ chips". JSON will be considered harmful, and XML will be in favor again because it is flexible and there's plenty of bandwidth for all the extra bytes.
  • mosselman 6y ago
    This isn’t new at all. This is version 7 of Turbolinks that has been renamed to Turbo and has some added versions. It has been what the Ruby on Rails and it’s creator have promoted for years and years. The new thing about it are the name and associating it with Stimulus and some features, not the general concept.
    • hadrien01 6y ago
• brtkdotse 6y ago
  This sounds a lot like server-hosted Blazor, streaming HTML snippets though websockets. Am I understanding it correctly?
  • freen 6y ago
    You are not.
• _verandaguy 6y ago
  Is this just PHP templating with extra steps?
  • Lio 6y ago
    It could be. Hotwire isn't tied to Rails at all. You could just include it in your existing PHP app if you wanted to.
• llimos 6y ago
  It sounds a lot like Laravel Livewire[1] Also a lot like React Server Components that we saw on HN yesterday[2] It seems like this is the next wave of web apps. Hopefully once the hype settles, we'll be able to decide which approach is best for which project. [1] https://laravel-livewire.com/ https://laravel-livewire.com/ [2] https://news.ycombinator.com/item?id=25497065 https://news.ycombinator.com/item?id=25497065
  • dsego 6y ago
    I wonder how recruiting companies will continue selling frontend react rockstars and backend nodejs warriors who can write endpoints. And yes, that's how they differentiate between frontend and backend, because knowing how to format your json urls (which is not real REST) is backend work and react is frontend.
    • etxm 6y ago
      > not real REST Rarely admitted, but absolutely truth.
  • sodapopcan 6y ago
    Livewire, of course, having been heavily inspired by Phoenix LiveView https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html
    • bnt 6y ago
      Tho, LiveWire is AJAX, while LiveView and Stimulus Reflex are Sockets. LW is a pleasure to work with for small pieces of interactivity.
      • dnautics 6y ago
        I believe (but could be wrong) that liveview degrades to http long poll.
        • deleted 6y ago
• somurzakov 6y ago
  Sounds like Phoenix LiveView. I love phoenix <3
• lxe 6y ago
  These folks literally invented Ruby on Rails and were building web applications for over 20 years now. This tech seems "old" but it's solid.
• JeremyBanks 6y ago
  This kind-of tangential reply is in bad taste, but DHH is currently being an asshole about this very topic on Twitter, so: This seems cool, but the progress that HEY has made since launch isn't very impressive if that's the flagship example. HEY's search UX, which uses these capabilities, has been abysmal since the day it launched. It's a much better experience if you disable JavaScript/Hotwire and fall back to the server-side-rendering instead of the hybrid mess they push down. I'm very disappointed that this hasn't been improved. (I sent feedback about this while they were still in their invite-only phase.) We were also promised custom domain support by the end of the year, and we don't have a timeline or even pricing yet. (That's obviously backend and unrelated to this announcement.) I don't want to go back to Google, but the lack of improvement isn't giving me a lot of confidence as a HEY customer, so I'm considering alternatives.
  • ksec 6y ago
    >We were also promised custom domain support by the end of the year, Basecamp / DHH generally speaking hate deadlines / roadmap etc. They are ready when they are ready. Although I do agree a little update would be nice.
  • bschne 6y ago
    I‘d be curious to hear about your general experience w/ hey - from the outside it looks like it has some cool new(er) approaches, but I‘ve seen someone‘s actual full email account in a screencast once and it looked like it‘d get messy with actual heavy usage really quickly and the UX might deteriorate. Any takes?
    • save_ferris 6y ago
      Not OP, but I have a Hey account and I really enjoy it. The screener feature is worth the price alone IMO. The biggest challenge for me was having to re-conceptualize email after switching over since Hey doesn't use traditional email terminology (i.e. "paper trail" vs "archive"). The amount of inbound email I get has dropped immensely due to the screener and my inbox ("imbox") is so much easier to manage with Hey, IMO.
    • 6y ago
• deleted 6y ago
  [deleted]
• sdevonoes 6y ago
  Is this a joke? What's new about sending HTML over a TCP connection?
  • capnorange 6y ago
    the dev experience
  • dogsgobork 6y ago
    For a minute I thought it was the html version of vanilla-js http://vanilla-js.com/ http://vanilla-js.com/
• elamje 6y ago
  This is the Ruby on Rails version of what Elixir Phoenix Live View and .NET Blazor do. For those not familiar, rather than using a standard web framework where a lot of processing is done client side, these frameworks allow html buttons etc to call native Ruby, C#, or Elixir functions on the server rather than using some sort of post/get request to do that. Every UI interaction goes over the wire, which is where performance can be hurt. Having used Blazor in production for nearly a year, it speeds up development, but your server is doing a lot more processing and will not be able to handle an equivalent amount of users that a normal web app would because it’s keeping a copy of the clients DOM in memory. It’s updates the dom on the server then streams that update through websockets to the clients dom, creating your magic Single Page App experience. I think it’s cool tech, but not necessarily scalable due to the increased server load. I’d be interested to hear from people using it to serve large orders of magnitude of clients at once.
  • BryanBeshore 6y ago
    Any idea how many people use Hey.com? That might be an early indication as to how scalable this is (at least for hotwire's concerns)
    • simonw 6y ago
      GitHub scales just fine on their own variant of Turbolinks.
      • BryanBeshore 6y ago
        Agreed. My comment about scaling is simply that a lot of other companies use rails at scale, and alike that of hey.com (which I presume is heavily used) it is probably built to... scale
    • ksec 6y ago
      Well Rails was never not scalable in literal sense. It was just the cost of scaling being expensive; comparatively speaking when people say Rails not able to scale. And for most if not all SaaS that should never be much of a problem. Because you are getting revenue per user, and generally speaking the cost percentage of user / app / server resources is so small, that is a rounding error in grand scheme of things. What doesn't work quite as well is when the app is operating a freemium / ad based model. Where a large volume of traffic are required before you start generating revenue.
• w_t_payne 6y ago
  Reminds me of HTMX
• deltron3030 6y ago
  My first thought was that some dude is ripping off LiveWire and Turbolinks because of the strange centered text (no professional web designer would do that), until I saw that those were renamed evolutions of those technologies from Basecamp, cool!.
• nlh 6y ago
  Gotta give @dhh credit - he is one of the world's great marketers/promoters. He's been building hype for this as the "next Rails" for months and the man knows how to pique an audience's interest.
• SahAssar 6y ago
  I've never seen one of these "logic in html-attributes" systems take error checking seriously. In stimulus they start to mention it in "Designing For Resilience" (though only for feature-checking), but in "Working With External Resources" where it uses calls network/IO bound calls they never mention how to handle errors or if the framework just leaves it up to you. Stimulus is also where you need to write your own js code, so I guess you could handle it yourself but in turbo when I skimmed the handbook I find no mentions of what/how to handle errors (or even what happens when turbo gets one), and when loading stuff over the network that is pretty much crucial. From the turbo handbook: "An application visit always issues a network request. When the response arrives, Turbo Drive renders its HTML and completes the visit." Using the phrase "When the response arrives" begs the question of what happens if it doesn't arrive, or if it takes a minute for it to arrive, or if it arrives but with a faulty status code.
  • memco 6y ago
    A very good point! Presumably the appeal of a system like this is the potential for graceful degradation where if sockets aren’t working or some requests are failing then the default html behavior should still work: links will just take you to the original destination, but there’s no indication that this is actually what happens.
    • inopinatus 6y ago
      This is an isomorphic fetch. The original href already is the visited URL, so I'm not sure that trying that again is wise, or appropriate, unless the user chooses to reload. The entire design philosophy here is to mimic apparent browser behaviour, or to delegate to it. Hence, to GP's question; you should expect the appearance of browser-like behaviour in any circumstance, modulo anything Turbo is specifically trying to do different. Deviation from baseline browser semantics was certainly a basis for filing bugs in its predecessor (Turbolinks). As for what Turbo actually does, I checked the source. Good news, even for a first beta, they're not the cowboy nitwits alleged; it gracefully handles & distinguishes between broken visits and error-coded but otherwise normal content responses, and the state machine has a full set of hooks, incl. back to other JS/workers, busy-state element selectors, and the handy CSS progress bar carries over from Turbolinks.
• pictur 6y ago
  Hype hype hype hype...
• fergie 6y ago
  Gentlemen, we have come full circle.
  • wnevets 6y ago
    web development has jumped the shark, I thought this was a parody at first.
    • jtms 6y ago
      reminds me of the http://vanilla-js.com/ http://vanilla-js.com/ which is actually a parody, but also... not?
  • acabal 6y ago
    I thought this had to be satire when I opened the page. Now I'm still not sure.
    • rk06 6y ago
      I thought it was a joke. and completely ignored it when i first saw the headline. only later someone else referred to DHH's hotwire. it clicked me that it is the New Magic thing. I am still wondering if there is any benchmark presenting some objective facts
    • therealmarv 6y ago
      I'm also still not sure. Also thought this is satire.
  • gassius 6y ago
    Wait, we still need to add a cgi-bin to this
    • bengalister 6y ago
      cgi-bin has been rebranded serverless: running external processes to the web server.
  • 6y ago
• dperfect 6y ago
  Is this the "new magic" that DHH teased on Twitter, or are we still waiting to see what that is? Also, should we expect this to be included in a future version of Rails? My first impression is that the API seems a little convoluted, but that might just be me. In an ideal world, I'd love to just build components (similar to React components) on the server side, and let the framework intelligently handle synchronizing state over the network (Phoenix LiveView seems closer to that), but this feels like it involves a lot more framework-specific logic (and markup) with special cases - stuff that's likely to change as the framework evolves, so I'm not sure how I feel about it. I guess it makes sense in terms of making this easier to add to an existing rails app incrementally (since it's more-or-less "opt-in" for each model, view, and controller), but if I'm building a new project with this and want it on everything, it feels like it will necessitate a lot of code duplication. Either that, or I use it judiciously only when absolutely needed (and use traditional rails behavior for everything else), but that feels like a mess of two very different approaches bundled together in one codebase.
  • simonw 6y ago
    Yes, this is the "new magic".
  • pdxandi 6y ago
    You should check out React Server Components.
  • arvindamirtaa 6y ago
    Yes this is the new magic stuff. But I doubt they'll integrate this into Rails. They'll just create better and better tooling to make using this with rails a cinch. I think this will just remain backend agnostic, like turbolinks and stimulus were before "hotwire".
• deleted 6y ago
  [deleted]
• newsbinator 6y ago
  I'd like to try a version of this outside of Ruby/Rails.
  • danjac 6y ago
    I use Turbolinks for some Django projects, so took a look at how much work it would be to port these over to Hotwire/Turbo. Very little in the way of docs to go on right now and what little there is in the way of examples is buried in Rails gems. Should be mostly straightforward, with a thin Django middleware to check headers and the like. I guess The Turbo Stream stuff could be adapted to Django channels quite easily. I'll wait and see how and when they improve the documentation, especially on the Rails-agnostic front.
• kaleidawave 6y ago
  There will be a very hot wire when I have to ask the server to render a component on the server after I asked to increment a single counter
  • jtms 6y ago
    it might not be so bad <div id='counter'>42</div> is not so many more bytes than... { counter: 42 } also - no massive up front JS bundles to contend with
    • kaleidawave 6y ago
      Assuming that the counter state is on the client. A button with an event listener that runs x.innerHTML = state.counter++ makes a lot more sense than a round trip to the server. Just looked and Turbo is 135kb. I rewrote this website (http://40.115.126.159/ http://40.115.126.159/) with my own JS framework and it comes at 15kb, that's 9x smaller Turbo...
      • Lio 6y ago
        In that case you could avoid making the round trip completely by just adding some native JS. There's nothing in Stimulus or Hotwire that prevents that. I think they actually mention adding Stimulus controllers in the demo video for those usecases.
• mdoms 6y ago
  Spoiler, it's just Ajax but it pushes the data through your templates before sending it to the client. We were doing this literally over a decade ago in the early days of XHR.
  • weeboid 6y ago
    Isn't the point that it's a framework to accomplish this, rather than "look what we can do!"?
  • aantix 6y ago
    The goal is to have a productive set of patterns for the programmer to follow for dynamic updates. Less boilerplate. More reuse. Consolidation of app state to the server. Feel free to post your code from a decade ago so that we can do a bake-off and compare implementations side-by-side.
    • lmm 6y ago
      Look at any of Wicket 1.4's Ajax examples (bonus if you use a better JVM language to reduce the boilerplate - I was using Scala). It's a great technique, it works great, I'm just slightly salty that the industry felt the need to switch to JS SPAs for, as far as I could see, very little tangible advantage.
  • joelbluminator 6y ago
    Oh no, a decade ago!! please show me some hot new Next/Redwood/Svetle code so I can calm my nerves!
  • Osiris 6y ago
    I have a small website and I have one page with an order form and I show a modal with the result of the order. This is how I do it. The Ajax calls gets back HTML that it shoves into the modal. It was just easier than writing JS with templates and parsing JSON. It always felt icky to me because that's not the way you're "supposed" to do it, but it works quite well.
    • 6y ago
• ghego1 6y ago
  A while ago, way before SPA were cool and even AngularJS was around, I had done something sort of like this, based on Ajax calls though, so the underlying tech was definitely different. While this is truly clever and being based on sockets does seem to simplify communications between client and server, I'm not fully convinced. Currently I see client side rendering as a way to delegate some computing to the clients. Which is a nice way to lower operating costs. I can see the benefit of this and the reasoning behind it. Because SPA still need a server (serverless still implies server side coding) as long as you are executing code on the client you need two codebases. One for the client, one server side. With this solution it would seem that it's possible to serve a web app with only one codebase, so that's definitely a plus. But then performance and costs do preoccupy me a little. Perhaps the ideal scenario for this tech would be for (enterprise) apps to be deployed on proprietary servers, where scale is a minor concern.
  • marcosdumay 6y ago
    The one performance concern on distributed systems is on data coherence. You optimize it, and treat anything else as relatively free. Rendering (or anything else that you can choose to do on the server or the client) has no impact on data coherence. Thus, as optimization goes, it's something you care about less than nearly anything else. By the way, I have seen my share of really horrendous code though my life. Only twice I have seen something that isn't data coherence being a bottleneck to anything. Both times were really stupid bugs.
• saltcod 6y ago
  This all seems super cool, but mega complicated. I'm not in the Rails ecosystem at all, so would love someone's assessment. Is this a new, giant complexity or a nice add-on? A huge mental/development shift or a nicely paved new path to something better?
  • davish 6y ago
    If you're used to SPA-style frontend development with React, Vue, or any similar framework, then yes, this will probably be a big mental/development shift. Turbolinks (the project at Basecamp that Hotwire grew out of, now it seems it's called Turbo Drive) was a way to bring single-page style load times to traditional, server-rendered apps. Hotwire is the evolution of that: Turbo Frames let you dynamically replace certain parts of the page on the frontend, rather than having to throw the baby out with the bathwater on every page action. If you're used to developing server-rendered applications without much JavaScript using Ruby on Rails, Django, or a similar "batteries included" backend framework, then you'll be able to add a more dynamic feel to your web app without much of a mental shift: certain template partials (basically the components of your frontend) will be wrapped in this `turbo-frame` HTML tag, which will be slotted in to your page dynamically by Turbo.
  • eecks 6y ago
    I agree. This seems complex but I am NOT a rails developer. The least complex stack I can find is Svelte (with Sapper) on the front end that calls out to API made in Spring Java. That lets me have quick development on the frontend, server side rendering for fast first page load and use of a typed language for the backend. The client is also overburdened with a large JS framework.
  • Trasmatta 6y ago
    > mega complicated I would argue it looks a lot simpler than the average SPA framework or library.
  • dsego 6y ago
    More complicated than having to deal with auth, routing, validation, xhr, application state, business logic in an SPA? And write your endpoints again with another round of routing, auth, validation, business logic. And then integrating everything.
• deleted 6y ago
  [deleted]
• underdeserver 6y ago
  Laugh all you want but the hey.com website loads wicked fast.
  • petee 6y ago
    Why wouldn't it? It's got like 2 pictures and isn't long. I also wouldn't call it wicked fast - this is normal speed, which everyone seems to have forgotten
    • underdeserver 6y ago
      The landing page has a lot more than 2 pictures, but also the rest of the website is fast. Show me another modern-design website that loads that fast.
      • petee 6y ago
        Either way it's still under 400KB for the whole site, it had better not be slow. Not sure what modern has to do with it. By comparison of a similar design, golang.org is twice the size and only takes .3 seconds longer. So what exactly are we comparing?
    • mrmonkeyman 6y ago
      Sorry, this is right. You have all forgotten about how fast the normal web is or are too young to have experienced it. Sub 100ms is normal. 1000ms is not normal.
    • arvindamirtaa 6y ago
      Go ahead and load the hey login page. The js bundle your browser downloaded right there is the entire bundle for the whole email app. What size is it?
      • petee 6y ago
        49kB, and for the most part it's not executing, so what's your point? There is no reason that shouldn't be fast, regardless Not trying to stray too far from my original point, loading a small page with not alot going on should be fast. I'm not knocking Hey.com, I am just not going to pass out accolades for making a properly usable site!
• OJFord 6y ago
  'HTML over the wire' is an unfortunate tagline, but it does actually seem interesting, I'd suggest looking at the 'Turbo' docs before reacting. I have thought in the past I wish I could have a frameworky component-style frontend, but where the component is HTML rendered by my rust (or whatever) backend. This would seem to get me a lot closer to that.
  • jshen 6y ago
    Yes, I’m curious how hard it is to get this working with a different backend stack. I’d love to have this in Go.
    • arvindamirtaa 6y ago
      Getting turbo is trivial on any backend. Just include the js. Stimulus is also not any different from any other javascript you'll write. There's no need for any kind of scaffolding from the backend stack except for some features - and those aren't particularly hard to implement either. Source: Using Turbolinks & Stimulus js with Django.
      • jshen 6y ago
        Thanks, I need to read up more on it. When I look at the rails code, I see a lot of nice convenience capabilities in the template definitions and rendering.
• antoineMoPa 6y ago
  The downside of this is very high coupling between the frontend and the backend. However, many companies have been successful with strong coupling to Rails so maybe it's not a problem.
  • dsego 6y ago
    The backend here _is_ your frontend. Nothing stopping you from adding another service layer behind it.
    • antoineMoPa 6y ago
      The backend here _is_ your frontend. This supports my argument that there is tight coupling.
      • dsego 6y ago
        Between what? Your frontend is serving the html/css/js, that's your frontend. You can have another background service behind it, as many layers as you want. This separation doesn't have to be at the http level.
        • antoineMoPa 6y ago
          Let's say you take another approach. Build a backend that serves REST, GraphQL or whatever protocol. This can be a Rails backend, could be Python, JS, whatever. Now you or the frontend team are free to build the frontend with whatever technology. You can update it more freely to shining new JS frameworks because it is not entirely tied to your backend. Also, if your client/boss asks you to build a native IOS frontend, you already have built an API, useful no?
          • deleted 6y ago
            [deleted]
          • dsego 6y ago
            > You can update it more freely to shining new JS frameworks because it is not entirely tied to your backend. With proper architecture, you would have stores & services as the main boundary of your app. Then you can easily consume them in your server-side rendered pages or JSON API endpoints, which are then just thin wrappers. >Also, if your client/boss asks you to build a native IOS frontend, you already have built an API, useful no? My client wanted email forms to improve engagement. And it was not a theoretical request.
• staticelf 6y ago
  I love that these new techniques come out to make web dev simple again. I however think Phoenix Liveview is still the best from all the alternatives I have seen so far and that is mainly because Elixir as a language seems to be very stable and suited for having a lot of websocket connections open at the same time. It seems easier to accomplish this with Liveview and perhaps Alpine.js for displaying stuff like modals etc. It's a really good way to build applications I think for places that need a server roundtrip anyway which is most of the stuff in a modern app. I write a SPA app for work in javascript and about 90% of the issues that occurs are mainly state issues where the state differs or is in a bad state for some reason. State management is very hard to do right and I think solutions like these simplyfies it a lot! I urge people to check out Elixir and Phoenix Liveview which I think is the "original gangsta" when it comes to sending small updates over websockets and if you try it I will guarantee you will be blown away of the speed of which you can develop web apps as a solo dev.
  • fortran77 6y ago
    I've been using Phoenix LiveView and I love it. I'm much more comfortable with Erlang syntax, though, and wish there was still a viable Erlang web framework.
• tmakks 6y ago
  tldr content marketing for Hey (email web app), carries DHH signature + cargo cult + magic, many social media bots/DHH fanboys upvoting comments + a second submission + silencing other opinions Edit: As I predicted, I've got my downvotes by DHH's social media team haha.
• naikrovek 6y ago
  amazing. This used to be called /cgi-bin/ with templates and XMLHttpRequest (a Microsoft invention initially supported only in IE then adopted by everyone) and now it's suddenly a new technology/approach but with a new name so you're not ridiculed for using it? I gotta give them credit for revisiting server-side page assembling though; moving application logic and templating mostly to the front end was a HUGE mistake. JS is very fast now, but it's still absolutely glacial in its speed compared to server-side code written in compiled languages.
  • jshen 6y ago
    cgi-bin didn’t give you the ability to update a chat page across several different windows in near real-time.
    • naikrovek 6y ago
      It did if you used XMLHttpRequest.
      • jshen 6y ago
        If you type a chat message in your browser, how does it automatically show up in my browser with XMLHttpRequest?
        • icedchai 6y ago
          In old school chat rooms, this was usually done by polling for new messages every X seconds, or doing a refresh / reload of an IFrame containing the chat.
          • jshen 6y ago
            I know, I wrote many of those, it’s a much worse solution than this.
        • fzzzy 6y ago
          Long Polling is how we used to do it. The web page opens a request to the server but the server does not reply. Once the event happens on the server, the server replies to the old request and the client opens a new request.
• joelbluminator 6y ago
  Hotwire sells like hot cakes!
• sourc3 6y ago
  This is so exciting to see, especially for older folk like me. Almost 20 years ago, one of my professors told us before graduation that hot tech is mostly about the idea pendulum swinging back and forth. I immediately chalked it up to 65+ above white wise men snobbery. However, this is exactly that. We started with static pages, then came Ajax and Asp.net and the open source variants, then we went full SPA, now we are moving back to server side because things are too complicated. Obviously tech is different, better, more efficient but the overall idea seems to be the same.
  • dgb23 6y ago
    I don't think this addresses all of what SPAs is used for. It seems to assume full-stack control.
    • Trasmatta 6y ago
      It's specifically built for Rails, so yeah, it definitely assumes full-stack control. And there are definitely applications I would prefer to write as an SPA over the Hotwire approach. But given that the vast majority of websites are just a series of simple forms, I prefer this approach over the costs you incur from building an entire complex SPA.
      • mfer 6y ago
        While it works with Rails... some of the parts are just JavaScript and will work with any underlying platform.
  • bzb6 6y ago
    Nice casual racism you threw in there.
    • craftinator 6y ago
      .
  • mfer 6y ago
• 1f60c 6y ago
  I wonder how long it will take before we reinvent SPAs? I like Hacker News in part because the tech is so boring. Server-side rendered, static HTML with a minimal amount of JS[0]. [0]: https://news.ycombinator.com/hn.js https://news.ycombinator.com/hn.js
  • freedomben 6y ago
    I also prefer boring and love how HN works. That said though, modern consumers expect much more. We tech people like command lines, the ultimate in simple and boring. Modern consumers often want animation and things[1]. Source: UI/UX researchers tell me this when I push back and say "let's keep the tech simple and forgo some of the animations, etc in the name of using simple OOTB stuff without hacking thousands of lines of JS together." Also family members will tell me the same things.
    • matthoiland 6y ago
      Consumers want electronic starters on their chainsaws – but they're less reliable, prone to error, more expensive, etc... in the end, us engineers gotta make products that people will buy.
    • rorykoehler 6y ago
      Do people really want that stuff out do they just think they want it?
      • scythmic_waves 6y ago
        If you have trouble selling a product without that stuff, does it make a difference?
      • trog 6y ago
        Do people think they want it, or do developers and designers think the people want it?!
      • jolux 6y ago
        I'm a developer and I definitely want that stuff some of the time. On platforms that can handle it, absolutely. I love all the animations in macOS and I always have. GNOME and Windows are nice but they don't feel like home in the same way, they don't have sophisticated and fluid animations. They need to be performant and they need to improve the usability of the system, not reduce it. That's the criteria. It's often not achievable with the web, though people try.
• ashton314 6y ago
  Can someone familiar with this please diff it with Phoenix LiveView? https://github.com/phoenixframework/phoenix_live_view https://github.com/phoenixframework/phoenix_live_view
  • strzibny 6y ago
    LiveView does not need Redis, nor does it depend on any particular background job processing solution. It's plenty fast and minimal. On the other hand does not support or plan to support mobile use-cases. Others can chip in to expand on this ;).
• johnghanks 6y ago
  i don't get it. isn't this just traditional SPAs but worse and more limited in basically every way?
• tarsinge 6y ago
  This is exciting! I am less convinced by the Stimulus part though. I currently prefer the Htmx (ex Intercooler) + AlpineJS combo, or VueJS components sprinkled into views for heavier stuff (setup is a bit tricky but then it’s very easy to enhance views with augmented html). Am I missing something?
  • dmix 6y ago
    Yeah there's a million ways to do this already with JS frameworks or even combining them with Rails. It's trying to standardize a fullstack approach to it I presume.
    • tarsinge 6y ago
      I agree with the need of standardization. But it’s just that I find the above mentioned libraries “hyper declarative” approach more in line with an HTML centric philosophy than the logic in a JS controller approach of Stimulus.
• deleted 6y ago
  [deleted]
• tecnocriollo 6y ago
  Like old fashioned PHP
• ausjke 6y ago
  SPA moves all the routing/templating to the browser side. server side rendering does it all on the server and spits out html(legacy cgi style) between these two: static html template downloaded from the server, then use ajax to update json in the html pages, which is the old boring way but it might still be the best middle ground? Unless I need make a desktop complex GUI program where SPA could be a reasonable choice, I will just do the html/ajax old way, not fully geared towards to server or client side rendering, life is much easier.
• jack_riminton 6y ago
  Most of the comments here are along the lines of: this is old tech! But this isn’t really about the tech, it as much a productivity hack that allows people to be much closer to that old fashioned concept of a full stack developer This is what has allowed Basecamp to create Hey with a team just a fraction of the size of their competitors
  • ljm 6y ago
    Somewhere along the way Mythical Man Month was turned from a cautionary tale into a competition, and it only ever seems to happen once VC gets their mitts on a company. Does it really take a team of 800 engineers to maintain your fancy todo list app, rather than your focussed team of 10 or 20? What are all of those people doing except piling on organisational cruft so the business has no choice but to over-encumber itself with talent? Most of them aren't working on the product, that's for sure.
    • jack_riminton 6y ago
      Yeah somewhere along the line people confused success with the amount of money you’ve raised and the number of people you employ. This just incentivises complexity
    • notsureaboutpg 6y ago
      At scale, yeah it does take a lot of people to do this. It has nothing to do with the type of app and everything to do with how business works. At scale you have huge enterprise customers with complex setups and they want to integrate your fancy todo list app into their setup and will pay you tons to do it. Your fancy todo list app suddenly needs to have all sorts of security certifications, needs to guarantee some type of uptime, needs to be able to integrate with all sorts of systems and other products (some of which none of your current engineers will have experience with). A new device will be released (think Apple Watch) and you're leaving money on the table if you don't hire some engineers to put your fancy todo list app on that platform along with the 5 or 6 others it's already maintained on. At scale, 1 in a million type bugs/problems come up every day and you need more engineers to deal with them. At scale, you are generating and producing (and thus need to be collecting and analyzing) an amazing amount of data, which should be used to better your product, learn about your customers and try to grow your business into providing other products and services your customers want / need. All that data collection, storage, and analysis requires more and more engineers.
• poxrud 6y ago
  I'm curious how this is different from Turbolinks, which was been available since rails 3.
  • staticelf 6y ago
    Turbolinks afaik, loads a larger part of a page upon hover and click, replacing all of the old html while this only updates the parts that has needs updating. This will prevent forms from being cleared or other state in the DOM to be wiped.
    • werdnapk 6y ago
      Exactly. Targeting specific sections of the page is pretty helpful when dealing with dialog content for example. If a dialog is open and you're managing something like the state of a form within that dialog, you don't want anything else outside of that dialog content being touched during a page update.
  • latortuga 6y ago
    "Turbo Drive", one of the parts of Hotwire, is a rebranding of Turbolinks. So it's new functionality on top of Turbolinks.
• alunchbox 6y ago
  How do they intent to not have "Send massive files without using other apps" being abused? Isn't this one of the key reasons to use a separated system. I can see this becoming a big problem on their ecosystem if it starts to scale it'll start to be very costly.
  • arvindamirtaa 6y ago
    They charge $100 a year. It already is very costly (for us).
    • kawera 6y ago
      $100 per month: https://basecamp.com/pricing https://basecamp.com/pricing
      • Axsuul 6y ago
        https://hey.com/pricing/ https://hey.com/pricing/
• phaedryx 6y ago
  I wish they'd document how to write tests for this stuff. Also, I wish they'd provide an example with multiple moving parts.
  • Axsuul 6y ago
    Yep–without good testing support, it's hard to consider this for production usage.
• zemnmez 6y ago
  from a security engineer's perspective, these things seem great, but ultimately become really tricky where DOM nodes need to be produced safely. string concatenation doesn't cut it for obvious reasons, then you have mXSS from mismatches between the backend server and the browser's interpretation of the HTML
• rubyfan 6y ago
  This is sort of ironic because many years ago what caused me to move functionality to client side was the fact that Ruby on Rails was slower on server side and required horizontal scale and things like memcached to meet my demands.
  • deleted 6y ago
    [deleted]
• deleted 6y ago
  [deleted]
• ivanhoe 6y ago
  Laravel's crew had a very similar idea with Livewire (even the name sound similar, probably not intentionally) and it also created a lot of buzz back when it was released - but I don't think it really got past "let's play with it a bit" step for most of teams. We'll see how well this one does...
• bcheung 6y ago
  What are the pros and cons of this technique? Seems like this pushes a lot of the rendering compute power from the client to the server. I guess that is good for low power devices but now you need more powerful servers?
• dorkandstormy 6y ago
  Am I the only one who was very, very surprised when the screencast immediately jumped into Rails? There's no mention of Rails anywhere on the landing page.
  • yopo 6y ago
    Ya same here. I've been doing web dev for 13 years and was genuinely looking forward to this magical HTML only solution of theirs but left feeling deceived after finding out it's rails.
    • arvindamirtaa 6y ago
      It's not rails. It's very specifically backend agnostic. Source: I've been using turbolinks and stimulus with Django for a good year and a half.
      • vigneshacker 6y ago
        Hi, is it available in your public github repo?
  • joelbluminator 6y ago
    Frankly Im surprised you aint using Rails!
• goshx 6y ago
  Next year they'll come up with hosting your websites on your own bare-metal.
• grumple 6y ago
  This is a continuation of existing Rails ideas: "This is a conceptual continuation of what in the Rails world was first called RJS and then called SJR, but realized without any need for JavaScript. The benefits remain the same" [1]. So if this doesn't wow you, that's why; Rails already largely can do this, but you have to write some javascript yourself. This does seem simpler for the toy example. I'm curious as to how it works with nested templates, there are no examples for it that I noticed. 1. https://turbo.hotwire.dev/handbook/introduction https://turbo.hotwire.dev/handbook/introduction
• stanislavb 6y ago
  For those interested in the source code, here they are the repost of the mentioned tech: - Turbo (HotWire) https://github.com/hotwired/turbo https://github.com/hotwired/turbo - Stimulus https://github.com/hotwired/stimulus https://github.com/hotwired/stimulus
• poisonta 6y ago
  It took a decade for the industry to realize that JS frameworks were overhyped and the degraded productivity because of them was not worthy. I think they will be replaced by Hotwire-like technologies in the next decade. The same thing will happen to micro services (especially, distributed monolith) and Kubernetes. They are just overhyped. Productivity matters most!
  • le_didil 6y ago
    I don't think this is going to happen. Hotwire-like technologies have existed for a long time with turbo-links, adoption is low and it's very unpractical to work with compared to a split backend api + frontend (framework or not as you prefer).
    • arvindamirtaa 6y ago
      >it's very unpractical to work with compared to a split backend api + frontend This is just demonstrably false. Both paradigms have areas where they shine. One or the other is not better across the board. I guess the point of Hotwire is that there isn't pretty much anything you can't do with the "old tech" that you can with the modern javascript CF.
  • Nextgrid 6y ago
    The last decade in tech has shown that productivity does not matter most and I'm not sure the pendulum is swinging back (yet?). The only time productivity matters most is maybe small, bootstrapped businesses where cash isn't infinite and actual value delivered is what matters. In fact, the company behind this is Basecamp which is almost an outlier in tech at this point, as they're one of the few out there that actually makes its $$$ by selling products/services people pay money for, as opposed to endless VC money or acquisitions. When it comes to VC-funded crap or big legacy enterprise trying to "modernise" itself, over-engineering allows grifters to twist the situation for their own personal gain. The business problem the tech is supposed to solve often warrants a simple solution, but why would someone solve it with a simple solution and 3 people when they can bring Kubernetes, microservices, "service mesh", blockchain and multiple programming languages to the mix and suddenly become an "engineering manager" managing 30 people, put big words on their resumes and speak at conferences about how they solve big (self-inflicted, as a side-effect of the overengineering) problems where more of their peers (either new and genuinely believing this is the proper way to do things - like I once was - or experienced enough to know this is BS but support it as it paves the way for their own career) encourage them? This happens at multiple levels too, it's not just developers or would-be engineering managers. The funding side of things is also broken in the sense that you'll attract more investors and raise more money (some of which you'll keep in your pocket as salary, even if the company folds in the end) if you throw big words and pitch an over-engineered solutions such as blockchain as opposed to a simple and proven one (even though the latter is more likely to actually pay off).
• korijn 6y ago
  I chuckled when I read "traditional singe page application". Anyone else share the sentiment?
• shrimpx 6y ago
  Where does this fit with the recently hot SSG/SSR projects like Gatsby and Next.js?
• mrtweetyhack 6y ago
  json payload is much smaller than html
• yashap 6y ago
  As others have noted, seems reasonably similar to LiveView, Livewire and Blazor. I’m somewhat bullish on these approaches - server side rendered monoliths (Rails, Django, etc.) are SO productive, at least for the first few years of development, but lack of interactivity is a big issue, and this solves it well. However, another big issue is the dominance of mobile. More and more, you’ve got 2-3 frontends (web and cross-platform mobile, or explicitly web, iOS and Android), and you want to power them all with the same backend. RESTful APIs serving up JSON works for all 3, as does GraphQL (not a fan, but many are). This however is totally web-specific - you’ll end up building REST APIs and mobile apps anyways, so the productivity gains end up way smaller, possibly even net negative. Mobile is a big part of why SPAs have dominated - you use the same backend and overall approach/architecture for web and mobile. I’d strongly consider this for a web-only product, but that’s becoming more and more rare.
  • ziftface 6y ago
    Everyone who is talking about how the route the industry took with SPAs was just a silly mistake, and that we should go back to the good old days of PHP are forgetting that at the end of the day the most important thing is to choose the best tool for the job at hand. This, while very interesting and might have a preferable set of constraints for some projects, is simply not a good fit for many others, as you mentioned in your comment. This looks amazing, and I would definitely try it for a project in which it would fit, but I don't really see a reason to disparage the work others have been doing over the past decade. We need those other tools too! (sorry for the rant)
  • arvindamirtaa 6y ago
    We gotta wait and see what Strada has in store. Looks like Basecamp and Hey mobile apps are fairly good.
  • clarkevans 6y ago
    > I’d strongly consider this for a web-only product, but that’s becoming more and more rare. They have accompanying https://github.com/hotwired/turbo-ios https://github.com/hotwired/turbo-ios and https://github.com/hotwired/turbo-android https://github.com/hotwired/turbo-android projects to bridge the gap.
• rajangdavis 6y ago
  A few years ago, I had this bright idea of updating a site I maintained to be a single page application (SPA). I was very inspired by this site (https://pocketjavascript.com/blog/2015/11/23/introducing-pokedex-org https://pocketjavascript.com/blog/2015/11/23/introducing-pok...) and thought it would make the user experience a lot better by making the site easier to navigate. I preloaded data such that a user could navigate via search or clicking through some drill-down menus without having to wait for a full page refresh. The data would hydrate the views so that the transition time between views was almost always fast, even on slow mobile traffic. One aspect that was very difficult to figure out was incorporating views that would require more data from the server. Once a user drilled down to such a view, the challenge became how to load the view via AJAX without having to make another AJAX call to load more data. The solution was to return server side rendered HTML instead of JSON... Looking at the demo, this seems very similar to some of the things I had to do minus 95% of the hacky Angular/PHP code I had to set up. This is a killer feature to have in Rails and I am looking forward to learn more of the conventions that will surround the implementation.
  • arvindamirtaa 6y ago
    >This is a killer feature to have in Rails Hotwire is backend agnostic.
• cs510 6y ago
  I'm a big fan of pure HTML pages because of performance and simplicity, but the techniques presented here are neither of those. For performance, server-side rendering is just bad. It won't scale to high volume traffic, cost too much money and is complicated to maintain. Hosting a static HTML files is more performant than that. For simplicity, the current protocol relies on so much "magics" to give the impression of simplicity. I think that's just an illusion of simplicity.
  • arvindamirtaa 6y ago
    If you can get away with hosting static html files, there's not much else that's more performant. The comparison is only between server rendered HTML vs backend API + some frontend rendering locally (which is not as performant) and more importantly is a lot more complex to implement technically.
• umaar 6y ago
  Two points on client-side JS have been a constant for me for many years: - Noticed excessive JavaScript contributes to poor web performance - Things cause JS to break, which breaks other interactivity, often I end up using incognito During lockdown, I struggled ordering groceries because 20 seconds of JavaScript execution on the main thread made my "delivery slot" expire! Similar to heydonworks.com stating "Please disable JavaScript to view this site", I'm glad Hotwire is encouraging folks to think about things a little differently.
• codethief 6y ago
  In case anyone from Basecamp sees this thread: The introductory video is far too long, far too technical (I know a lot about web dev but don't know a lick of Ruby or Rails) and far too fast to follow. I was really interested in Hotwire because of the comments here and now… not so much anymore. (Which of course doesn't say anything about the quality of the tech. I just thought I'd post my first impression of the website.)
  • mrblues 6y ago
    I agree. the video is terrible, nothing like the original Rails introduction screencast the tech is dope
  • nickjj 6y ago
    I'm not from Basecamp but it's interesting you mentioned it's too fast. I noticed that too and this is coming from someone who listens and watches everything at 2x speed. I've seen a lot of DHH's talks and demos and never had a problem listening to them at 2x. This is the only time where it feels like he scripted out the entire video word for word and then talked over a screen recording that was recorded separately from his voice. This video sounds nothing like what he normally sounds like (both tone and speed). I really wonder if he recorded this in a booth.
  • stevenhuang 6y ago
    Really? Well I'll be one to chime in that I found it perfectly follow-able and was able to get a quick high level understanding of what this is.
• modernerd 6y ago
  Pure JS developers trying to jump off the JS train have a few decent choices now: - Elixir / Phoenix - .NET / Blazor - Laravel / Livewire - Rails / Hotwire Or hold on for the JS ecosystem to figure out good patterns that balance performance/maintainability (React Server Components look ok, and will probably trickle into Next.js for those who want a framework). Does one of the above stand out as a good thing to learn from a career perspective, say, for a JS developer growing tired of frontend? Is the thirst for React developers ever likely to dry up and leave devs who know these frameworks with an advantage?
  • cutler 6y ago
    Well Blazor ain't gonna reduce your load front-end load, that's for sure.
    • learc83 6y ago
      Blazor has 2 variants. The server side version works like liveview.
      • cutler 6y ago
        How much is shipped over the wire with server side?
  • danielsokil 6y ago
    Also IHP (Haskell) has Auto Refresh https://ihp.digitallyinduced.com/Guide/auto-refresh.html https://ihp.digitallyinduced.com/Guide/auto-refresh.html
    • IggleSniggle 6y ago
      Thanks for reminding me about this. I really want to give IHP a try. Seems like a really nice design.
  • arvindamirtaa 6y ago
    It's really not Rails + Hotwire. It's any backend + hotwire. It works just fine with Django.
• kurko 6y ago
  You had me on "Oops"
• clementmas 6y ago
  What's the browser support for Turbo? It uses the History API, fetch, AbortController, etc. So Edge 16+, Safari 12.1+, FF 57+?
• elchief 6y ago
  wasn't this called Hijax back in the day? https://domscripting.com/blog/display/41 https://domscripting.com/blog/display/41
• danjac 6y ago
  So far, this looks very much tied to some Rails gems : documentation for installing outside of Rails is pretty much non-existent, I guess to be expected for a beta. My issue with Turbolinks/Stimulus is really that it's developed pretty much behind closed doors at Basecamp and we maybe get a shiny new release every few years, instead of being developed as a more open source project with incremental improvements and input from a wider group of contributors with diverse needs and insights than one small team at one company.
  • joelbluminator 6y ago
    Stimulus seems to have a very active Github page, maybe its more about the initial concept where Basecamp tends to be private?
• esroyo 6y ago
  Generally people argue that static HTML is more energy efficient than server side rendering. I wonder If that is true in the case of static HTML "that loads an SPA", versus a server-side rendering with a proper cache in place. The SPA loading will still consume good energy on each client computer. Would love to see some numbers. Lots of hype, lots of projects and approaches, and lots of opinons about what is more convenient, but few numbers measurements of resources (space, time, what more?). May be It silly me, and the difference in energy terms is irrelevant.
  • zelly 6y ago
    My intuition is that network transfer uses almost no energy, on a marginal basis, because the network links are always on anyway. When you pay for bandwidth, you're paying the amortized costs of building and maintaining the infrastructure. Rendering a SPA on a client device consumes CPU time, which definitely uses energy proportional to the number of client devices. Assume the server uses less clock cycles to render than the client--e.g., because of optimized software, hot caches, or tuned hardware. Therefore rendering on the server should always be more energy efficient than on the client.
    • esroyo 6y ago
      That is my intuition also. I heard Vercel's founder on some talk claiming the energy-efficiency of their approach, and thought that should be proved with facts (mostly because of the "x clients" factor you commented). Thanks.
• warpech 6y ago
  Not to be confused with Turbo by Yandex: https://yandex.com/dev/turbo/index/ https://yandex.com/dev/turbo/index/, which is a competitive take on Google AMP.
• iamleppert 6y ago
  I prefer to send updates to my web application as bitmaps. I do all the rendering of the HTML on the server to an image and just loop over the pixels and send a pixel if something changes from the last update. I call these updates “frames” and the client can even gracefully degrade — it can request a certain frame rate, or I can only send the luminosity value of a pixel, or randomly sample pixels to reduce detail for poor connections.
• OOPMan 6y ago
  Is this real?
• fzzzy 6y ago
  Hehe. I did exactly this in Twisted Woven LivePage in around 2002.
• metta2uall 6y ago
  Isn't this replacing the complexities of JS libraries like react/redux-saga with the complexities of these new server-side libraries..? Reduced bundle size looks like a big advantage & this will hopefully encourage the adoption of lighter front-end tech like preact/inferno/svelte. But the downside seems to be more resource consumption on the back-end, especially if using websockets, and so higher cost & more vulnerability to a DDOS? Also, what about offline support?
  • raihansaputra 6y ago
    Yeah, I'm interested about offline support. I might have to check out the HEY trial on web and on mobile. I think this HTML SSR approach have different tradeoffs and uses compared to Single Page Applications. The HTML SSR works best with a stable connection and being close to the server for good enough latency. Higher cost on the backend is a tradeoff on how much computation/complexity you want to offload to the client, and also what language/framework you want to work with more. Some HN comments from previous related topics suggest these approaches (Hotwire / LiveView / Blazor? / StimulusReflex / Intercooler / HTMX / Unpoly) fare better with apps targeting a specific region so roundtrip latency is lower. One can optimize the reads with DB replicas + app servers closer to any user, but the write DB is the bottleneck (I think). This also ties in with the feedback that US/EU HEY/BC users perceive the app as snappy enough while AU users feel the latency a lot more. SPA (properly built) should be more resilient in regards to network stability/condition/latency and expose a lot more offline capability. I feel like the ideal app is HTML SSR + an app shell to serve some offline capabilities. Scaling the write DB globally is a hard problem though.
  • frizkie 6y ago
    The overview video touches on how some components of the Hey app are aggressively cached, like menu popups and such - so I imagine your "offline" capability comes from the fact that anything you need to run the application offline is just cached from the last online use.
• webmaven 6y ago
  Okay this is a bit meta, but the whole cluster of "everything old is new again", "the pendulum of fashion has swung", "nothing new under the sun" takes is ignoring what tends to drive this sort of change: relative costs. The allure of xmlhttprequest was that over connections much slower than today, and with much less powerful desktop computers, a user didn't have to wait for the whole page to redownload and re-render (one can argue that focusing on better HTTP caching on the server and client might have been smarter) after every single user interaction. This was also much of the draw of using frames (which were also attractive for some front-end design use-cases later re-solved with CSS). As apps got more complex, clients got more compute, bandwidth grew, and as web audiences grew, offloadingl much of the page rendering to the client helped to both contain server-side costs and increase or maintain responsiveness to user interactions. Now, as desktop client performance improvement slows down (this isn't just the slowing of computer speeds, computers are also replaced less frequently), average bandwidth continues to grow, app complexity and sophistication continues to grow, but as server compute cost falls faster than audience size grows, shifting rendering to HTML back to the server and sending more verbose pre-rendered HTML fragments over the wire can make sense as a way of giving users a better experience.
  • voodootrucker 6y ago
    > The allure of xmlhttprequest was that over connections much slower than today As someone who implemented a SPA framework prior to "SPA" being a word much less React or Angular, I have to say for my company, it was all about state management. Distinguishing between web apps (true applications in the browser), and web pages (NYT, SEO, generally static content), state management was very hellish at the time (~2009). Before that, pages were entirely server rendered, and JavaScript was so terrible thanks to IE and a single error message (null is null or not an object) that it was deemed insanity to use it for anything more than form validation. However, with the advent of V8, it became apparent as an ASP.NET developer that a bad language executing at JIT speeds on the browser was "good enough" to not send state back and forth through a very complex mesh of cookies, querystring parameters, server-side sessions, and form submissions. If state could be kept in one place, that more than justified shifting all the logic to the client for complex apps.
• jessehattabaugh 6y ago
  As a web developer 20+ years, I'm just happy to see how much job security I have since none of you are smart enough to manage a React app and Webpack config.
  • togs 6y ago
    > As a web developer 20+ years Wow, that's dedication! > I'm just happy to see how much job security I have I'm glad for you! > none of you are smart enough ... Now I feel bad about myself!
  • joelbluminator 6y ago
    Job security? How old are you?
• rubyist5eva 6y ago
  Is this the Hot New Magic DHH was hinting at?
• asymmetric 6y ago
  > The heart of Hotwire is Turbo. A set of complimentary techniques for speeding up page changes and form submissions s/complimentary/complementary
• mfbx9da4 6y ago
  Products like Slack, Figma and VSCode will not benefit from this kind of technology. Get off of your old school horse. Not all websites are just websites. Performance is not determined solely by load time.
• nonsapreiche 6y ago
  Hyper Text was a very good way to link knowledge, but the Markup Languge evolved in the opposite way
• z3t4 6y ago
  I think the complexity/level is too high. You could easily do the chat from the example video in vanilla JavaScript with a Node.js server and Websocket, that would also be faster and smaller. The video was however a great tutorial, although a bit too fast. (I had to pause and replay a few times). But it did not sell me on the concept. A more simple approach would be to send a (head) request to the server every 5 second asking if the source/HTML/state has changed. Then do a sophisticated diff/replace of the DOM (like in React, but without React) making the smallest change to the DOM as possible (only change what was updated). eg. no full page refresh, nor iframes. (and also send a diff over the wire, not the full page). If you would make the app fully functional/pure you would then be able to cache many states (input->output) and predict them on the client and prefetch, for example a link click, would instantly do the DOM/diff and update the page with the new content. For example in a tic-tac-toe game you could pre-render all states and have the client pre-fetch them.
• still_grokking 6y ago
  Likely an unpopular opinion. But anyway. I think the presented thingy is fundamentally wrong. It's just another attempt to put the square peg in a round hole. The point is: "The web" is not, and never was, a framework for application development! It's the wrong tool. No matter how hard you try. You want to build applications? Use tools that where build from the ground up to support application development. On mobile people realized mostly by now that "native" is the way to go. Because native apps are superior along any dimension compared to "web-apps". The same is of course true on the desktop. Mature and full featured technology to build "native" cross desktop applications exists since forever. Just have a look at great tools like IntelliJ IDEA or Bitwig Studio for example. Hotwire on the other hand is just another try to misuse "the web" as an application development platform. It's closer to what the web actually is (namely HTML pages) but it's still wrong on the fundamental level (as it tries to build an app framework on top of something that was meant to be only a hyper-text system). Let's see how long it'll take until people realize this truth - and we're really full circle.
  • interpol_p 6y ago
    I agree with this. My favourite thing about the web is reading content with links to other content Wikipedia is a great example of a perfect web site: simply presented content linked together in a way that encourages exploration People keep hijacking this experience to make it "better" or more like an "app" but that detracts from what makes the web so magical
    • still_grokking 6y ago
      Even if Wikipedia had some interactive content (to explore some topics by playing around with stuff) it would be still fine. I'm not arguing against "interactive documents". I'm arguing that "the web" is not for full blown applications.
  • bird_monster 6y ago
    Best of luck getting paying users to install each individual desktop application, as opposed to installing a browser and then navigating to multiple applications without any additional desktop/native work. I guess there might be space for something like Steam, but for business apps, but I just don't see it. The argument "This isn't what the web was made for" is kind of a cowpath argument. The web is being used to (among other things) browse applications. Whether or not that's what anyone planned is irrelevant. That's what's happening right now. I think it's fair to suggest paths forward that both accommodate users and also bring sanity, but tagging every attempt at progressing applications-in-browser as "Square peg, round hole, need native app" just totally dismisses most of the users these applications are trying to capture.
• bird_monster 6y ago
  I hate javascript as much as the next person, but when I had to step into .erb templates and regress back into javascript-as-<script> blocks in HTML, holy crap did I realize how far the FE landscape has come. Watching the Turbo demo, I cannot fathom going back to erbs. It seems like DHH is just trying to make relevant tooling without writing Javascript, which I guess is fair, but given all of the advancements in all of the other tech, this really just does not seem like a good idea to me.
• mshenfield 6y ago
  The downside is that this makes it really easy for developers to avoid making an actual API. The turbo frames _are_ the API. Great to bootstrap, but miserable if you ever want to implement a native mobile app (or any other client) on top of the same codebase.
  • Lio 6y ago
    1. There's a library to add this into native apps fast. 2. In the case of rails (Hotwire is not actually tied to rails at all) it's really easy to turn any endpoint into a RESTful API, just use respond_to to send json or anything else being requested.
• benatkin 6y ago
  I'm currently more interested in processing content as JSON serializable abstract syntax trees, whether it comes from Markdown, HTML, or something else. The popular Markdown renderer Remark (https://remark.js.org/ https://remark.js.org/) supports this. It's based on Unified.js which has markdown abstract syntax trees (mdast) and HTML abstract syntax trees (hast). https://unifiedjs.com/ https://unifiedjs.com/
• wdiamond 6y ago
  I didnt see html, just ruby bindings. Anyone can make easy bindinds on server but it costs flexibility on components, imagine for deep nested levels customized components and syncing.
• CyanLite4 6y ago
  They’re (poorly) trying to emulate Blazor Server.
• kevlar1818 6y ago
  As a non web developer, writing less JS appeals to me, and I've found HTMX[1] to be simple to use. I'll add that the HTMX website/docs are much more approachable than this site. [1]: https://github.com/bigskysoftware/htmx https://github.com/bigskysoftware/htmx
• steve_taylor 6y ago
  We stopped doing this ten years ago because it tightly coupled the front- and back-ends and made it almost impossible to insert an API for mobile apps after the fact.
• aabbcc1241 6y ago
  Similar to intercooler.js and LiveView?
• neya 6y ago
  Could anyone explain what is the difference between this and LiveView from Phoenix/Elixir world?
• a-dub 6y ago
  Chiming in like all the other old farts... This is how I used to build web apps 20 years ago! :) Render all HTML on the server side using a lightweight templating engine, make page loads fast and make all interactions reload the current page avoiding all client side JavaScript for validation and logic. (except for hotkeys for quick nav)
• edwinyzh 6y ago
  I guess this is similar to htmx.org (was intercooler.js) which I like a lot! Will learn more about it later and I'm glad similar idea is getting more popular!
• ilaksh 6y ago
  Is the basic idea that you only transmit the new content when they click a link? Rather than a JavaScript application rendering it? So it's effectively similar to just a normal HTML page, but without things like headers and sidebars etc. being retransmitted? I guess I am old but I don't understand why this requires a multi-million dollar marketing effort and all of the other stuff they invented on top of it.
• pantulis 6y ago
  15 years ago RoR went against the bloated Java enterprisey frameworks, and after being dormant for some years now it's the time against SPAs. Time will tell --I'm not so bullish on Hotwire-- but one has to admire figures the likes of DHH that can almost single handedly change the status quo of the industry.
• lenkite 6y ago
  Intercepting clicks on all anchors and then replacing the body is something the browser should do and not the javascript library.
• supernihil 6y ago
  Lol. I made something similar: gihub.com/sloev/cccp As in sssr as in semi server side rendered
• thomas-guettler 6y ago
  I looked at several html-over-the-wire frameworks during the last weeks and wrote down my opinionated perspective. I think I will go with htmx. If you want to know more: https://github.com/guettli/html-over-the-wire https://github.com/guettli/html-over-the-wire
• jstummbillig 6y ago
  The crucial missing piece in this and LiveView, Livewire, etc is optimistic handling of client-side updates. It is not okay standard behaviour to have to wait a roundtrip to visually add a todo list item on the client. Afaik Meteor is the only major full-stack framework handling this. Any other takers?
  • habosa 6y ago
    This is a key point and I'd love to hear someone's thoughts on how you build an app with this framework that's snappy even on a high-latency connection.
• PanosJee 6y ago
  Would love to see a plugin for NextJS
• danjac 6y ago
  After playing for some hours with the new Turbo on a side project (with Django as backend), it mostly works fine. One thing that is kind of broken out of the box is form submissions: so a common pattern with server side rendering is to re-render the form with validation errors, but otherwise redirect to wherever. The workaround here I think is to use turbo-streams and just re-render the invalid form HTML snippet rather than the whole page. While this is probably ok for most cases, I have some forms (3rd party library stuff) where this is going to be more work than I'd like, and due to a bug in the beta release you can't override the default form submission behavior - Turbo throws an error if a form POST returns anything other than a redirect. So it's probably not quite ready for production yet.
• thomas-guettler 6y ago
  Htmx is boring. That's why I like it.
• corobo 6y ago
  Honestly couldn't tell if DHH's initial tweet was satire like vanillajs https://twitter.com/dhh/status/1341420143239450624 https://twitter.com/dhh/status/1341420143239450624
• mikerg87 6y ago
  Am I wrong to think this is like unpoly except it uses web sockets ? https://unpoly.com/ https://unpoly.com/