1. 57
  1. 35

    I looked at this page entirely too long before realizing they were serious. Initially, I thought they were making a point Vanilla JS-style.

    1. 23

      I’m excited to see the next advancement in the web development rube goldberg machine: maybe html over json serverless in the cloud?

      I wonder when people will rediscover/reinvent CGI scripts. That would be nice.

      1. 7

        Imagine when someone finds out that you can spit out HTML with AWS Lambda. It’ll be like the 90s all over again.

        1. 6

          They have. It’s Google Cloud Functions/Amazon Lambda/Google Cloud Run.

          All are basically ways to run your script or binary on shared hosting infrastructure.

          1. 3

            The SQLite project uses CGI scripts, written in Tcl using a “framework” called wapp.

            I use wapp for all my personal work because it’s far easier to keep up with than any pop framework (it’s a single 1008 line Tcl file).

            1. 1

              I quite like werc (http://werc.cat-v.org/) for simple web apps. I’ll check out wapp! Tcl is something I’ve never dove into before, should be interesting.

          2. 4

            So we’re sure it’s not satire then?

            It’s getting harder and harder to tell.

          3. 10

            I realize it’s different in implementation but I think it’s hilarious that for 20 years we’ve been moving away from frames and server-side rendering in favor of client-side scripting, XHR, and single-page apps and now this is talking about using frames and server-side rendering. :)

            1. 7

              It seems there has been some back and forth between the two paradigms during the past 2 decades. React just announced server-side components, which mimics what Meteor JS introduced several years ago. And some websites use a mix of server templates and client JS.

              I wonder what are the constraints that influence this evolution? increasingly large client-side apps? lower network speeds? larger and more diverse audience, with less-performant hardware and bandwidth? It’s interesting to watch – and I wonder how it affects framework adoption. It’s a lot easier for a new dev to learn jQuery than a framework that has client and server setup.

              Link to react blog post, where they touch on some of those design constraints: https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html

              edit: a co-worker shared https://htmx.org/ – strikingly similar to Hotwire. Check out the “motivation” section. It would make sense to me if the “best” solution lies somewhere between fully-bundled single-page app and an entirely server-side rendered app

              1. 46

                My going theory (and folks feel free to jump in on me for revisionism):

                For most of the aughts, we used to basically/mostly just have server-side apps.

                Ruby on Rails and Django come onto the scene around 2005, and by around 2010 startups like Github and everybody and their brother is using Rails or some equivalent.

                Unfortunately, these server-side frameworks are slow as hell compared to other ones of the time and so people start solving this by exploring the autoscaling tech tree (giving us products like Heroku) and the thick-client tech tree (giving us products like Backbone, Mithril, Angular, React, and so forth…tech already unlocked by things like Google Web Toolkit and Dojo years prior but hey, nobody wants to write Java at their startup). This is also around the time that CDNs started getting big, so companies like Cloudflare show up to offer hosting of assets.

                So, it’s like the mid 2010s and barring some weird evolutionary forks like MeteorJS we see that people are really all hot and bothered about Single Page Apps. This is further pushed by the rise of mobile apps, because everybody suddenly wants to use the same server backends to handle API calls while subcontracting to body shopscreating mobile applications alongside their web offerings, thus increasing shareholder value while being able to use dumber backends (and consequently, hire cheaper developers). Feeding this further, the 2010s saw the rise of services like Firebase and Zapier where your thick-client could talk to a service you didn’t have to host or program; you could glue together a startup without ever knowing anything about server-side programming and the accompanying ops/performance issues.

                The server (and server-side rendering) is toast, long live the server.

                Except. Except.

                Drunk on their successes and beers from conferences, the Javascript ecosystem just kept growing. And growing. And growing. In the 2010s we went from minimal asset processing (possibly raw files, maybe sprockets or similar if you were in Rails) to Grunt, Gulp, Browserify, and eventually Webpack, with pitstops for evolutionary dead-ends like Parcel and Brunch. At the same time, we started wanting to use languages like Typescript and even newer versions of Javascript that hadn’t formalized yet so we stole features from the proposal stages and brought them in using tools like Babel. Oh, plus, we decided that npm was not good at their job (npm 2 to npm 3 migration, anybody?) and so tools like yarn from Facebook came out to further confuse things.

                Anyways, all of this to say that a once-promising land was overrun by bullshit.

                A few ecosystems (I’m biased in favor of Elixir/Phoenix/LiveView here, but Turbolinks in Rails and I want to say some stuff over in PHP land also did this) discovered that a) they still ran plenty fast or their host language had sped up in the last decade, b) that dealing with the clownshoes of Javascript and thick-clients was excessively frustrating), c) Websockets were finally pretty reliably available, and d) all they ever wanted to do was patch subtrees of the DOM and give a-c maybe they could teach the server how to do this with a little bootstrapping on the client.

                And so now, server-side rendering is back on the menu.

                (As a colleague points out, Google also did a lot of stuff along the lines of Webpack earlier with Closure Compiler, and there are other beats I’ve left out due to ignorance or convenience, but I think this is a good rough sketch for people.)

                1. 11

                  Not revisionist at all, I think you nailed it, except I would also mention the vast amounts of effort that have gone into improving network and browser performance in the past decade. Receiving a chunk of HTML over the (typically fast) network and replacing a chunk of the DOM is now quite competitive with receiving some JSON, diffing a shadow DOM in JS, and making selective DOM edits.

                  1. 2

                    Fantastic. Thanks for sharing.

                2. 5

                  I had the same first thought but it looks like a significant difference with traditional server-side rendering is the idea to send partial page updates as HTML via websockets.

                  1. 4

                    Same here. Initially I thought “hm, this is exactly how we used to program Rails in 2006, but with better syntax to replace/automate away the manual RJS partial update mess”, but it’s the async websocket notifications that actually make this cool and viable for this brave new world.

                    It actually looks more convenient than manually setting up websocket communication and reading from an API in JavaScript. What really makes this neat to me is not having to touch a single line of JavaScript.

                    I wonder how well this translates to different types of applications, though. I seem to recall that back in the day, Rails was really good at building certain classes of web applications/sites but it didn’t do so well on other types of sites.

                3. 9

                  Soon PHP will be hip again with a few sprinkles of XmlHttpRequest in the browser ;)

                  1. 9

                    Now this is cool. Always wondered how hey.com was able to have such a small js footprint and just be so fast.

                    I swear Rails is just ageing like wine at this point, this is seriously cool.

                    1. 3

                      Interestingly, I find Hey to be annoyingly slow sometimes and it makes me wish for a native app. Thankfully, I recently found a tracker blocker plugin for Apple Mail and that’s really all I want.

                      1. 2

                        Where are you located? There was talk about people in Singapore having slow UI response.

                        1. 1

                          I’m in Cupertino, USA. I think it’s a combination of Electron and slow network calls.

                    2. 14

                      I wonder when they’ll finally get around to reinventing native applications. Imagine the fanfare when someone figures out how to write a program that works entirely without an internet connection. The future is bright.

                      1. 8

                        Reminds me of Elixir Phoenix LiveView - would be interesting to compare. The mobile native libraries are neat. Chris McCord, the Phoenix author, said that LiveView wasn’t a great fit for mobile due to latency issues. I’m super curious about how that plays out for HotWire.

                        1. 7

                          I’m not familiar with any of this “ speed or responsiveness associated with a traditional single-page application”. They seem universally slower and less responsive than traditional applications in my experience.

                          Though then again, I don’t live 2ms away from most of AWS.

                          1. 1

                            By “traditional applications” do you mean native apps?

                            I think the authors are comparing SPAs to server-side rendered web applications.

                            1. 2

                              Sorry, I meant traditional websites. I was unclear.

                              1. 2

                                A lot of the original motivation for SPAs was to decrease transition times when interacting with a page. Infinite scrolling lists, moving back and forth between tabs/views, etc all seemed totally magical when the techniques were first developed, and were in contrast to e.g. reloading the entire page on every interaction.

                                1. 1

                                  Yeah, but all of that comes at a huge cost of time to interactive, bogging down browsers on lower powered devices with megs and megs of javascript, putting slow javascript inbetween a click and a response, bloating memory usage, websites leaking memory, removing loading indicators, etc etc. Some of these things can be worked around or solved with better quality code, but A) they usually aren’t, and B) many of these things are fundamental.

                                  An example from a web application that’s usually considered quite good: GitHub. Most of my GitHub page loads are just opening a new tab to “check my GitHub feed”, because GitHub has successfully positioned itself as a social network and not just a place to host code. However, when I load GitHub, I first have to wait for the website to load, then I have to wait for the JavaScript to load and parse and execute, then I have to wait for some JavaScript-initiated HTTP request to retrieve JSON from the back-end, then the DOM updates and the site shows my activity. I used to be able to see my “feed” after one page load, and it would reveal itself incrementally as more HTML was received from the server. Now, it takes one request for the HTML, which initiates one request for the JavaScript, which initiates one request for the actual content I got there for. And because it’s JavaScript, the final request has to complete 100% before I see anything of the feed.

                                  If you don’t like GitHub, I’m sure your favourite SPA-like websites works similarly. GitHub is one of the better examples I’m aware of. Don’t even get me started on Reddit.

                                  1. 1

                                    Nothing to disagree with there, but I’ve been building large web apps professionally since 2005, and time to interaction was not necessarily better in the bad old days before SPAs. It still required a lot of optimization and understanding of all the disparate browsers’ performance characteristics, and if it was poorly done (and it often was/is), you’d have that whole crappy wait to load for every click. Not to mention the maintenance headache and code spaghetti you’d get when you tried to integrate some JS-based interactive elements into a server-side rendering flow.

                                    My point isn’t that SPAs are better, it’s that both SPAs and server-side rendering can be done efficiently or inefficiently and both have their place; plenty of evidence suggests you can misuse either technology quite effectively and make a junky site. SPAs opened a whole world of new interaction paradigms that just weren’t feasible before, especially without modern browser support. Since then people have figured out new technologies that let you develop a lot of the same style of lightweight, rapid interaction with both stateful (Elixir/LiveView) and stateless (This stuff) server-side rendering. Cool.

                          2. 3

                            Super condensed presentation, with masterfully edited voice over for a nice information flow. Loved to see how all this works in such a straight forward video. Such production quality is not something you usually see with FOSS.

                            1. 3

                              Love the comments. Now you know how the really old fogeys like me feel about posts like

                              • “_______ But It Runs In A Terminal”
                              • “NO ONE NEEDS LOWERCASE OR >40 COLUMNS”
                              • “Look! I Can Run Minecraft On This IBM PC XT”
                              • “Rediscovering GOTO: Why We Should Abandon Structured Programming”.
                              1. 3

                                I’ve released a new episode covering Hotwire. It’s really cool. I think that there is room for improvements, but overall, it’s going to be great. https://www.driftingruby.com/episodes/hotwire

                                1. 1

                                  I want to see the same thing but written in Go. The only one I know of (way before this ever came out) was Pepper