1. 28
  1. 12

    I feel really old just putting HTML files in a filesystem and letting nginx serve them via port 80…

    1. 9

      You’re not old, you’re ahead of your time!

      1. 7

        It’s like the old saying, as a man you just have to buy one good suit, and in 30 years it’s back in fashion.

    2. 8

      For what it’s worth, I believe that Elixir’s Phoenix framework uses a similar technique for LiveView.

      1. 5

        The differences are fairly important - Phoenix has long lived stateful processes on the server and only transmits minimal state diffs (not HTML) to be interpreted in the client.

      2. 5

        Me, reading, not noticing it was DHH… “Hey, this sounds like something DHH would probably love!” But I’m into it. Espesh if it can made to degrade to a “OK, it’s a li’l slower and you have to click manually but it works” version when there’s no JavaScript.

        1. 4

          It would be amazing if something like this was standardised, so that the client side could be implemented directly by browsers.

          1. 3

            Rendering HTML snippets server-side is a good idea until it isn’t. For most websites it should be a good approach, but you need to know the limitations and that they won’t be an issue in your case.

            If you need to consider a lot of client state when rendering, you either need to pass the full state on every request or to keep sessions server-side. And if you need more than one server instance, sessions become painful.

            And if you use the same data over and over to render a multitude of different views, both the bandwidth and the server load might become an issue.

            Cache invalidation is also something to think about, and I bet many people pick a React stack just to avoid thinking about what needs rerendering.

            We’ve been there before. So on one hand it’s tried and true technology, but on the other hand we (should) know the limits of the approach. I’ve personally seen very difficult problems caused by an HTML snippet approach in two different projects, and minor issues in a couple more.

            I’m no fan of modern web, but there are reasons we got where we are.

            1. 2

              I can imagine that a lot of sites could get by with the hotwire approach by having just enough client side state to avoid sessions on the server. Bits that need to be dynamic on the client can still be, and the server can still send JSON where needed. It’s more that the default approach is to have the server generate all of the visible stuff on the page, which can actually make cache invalidation/state management issues on the client side much simpler.

              You wouldn’t make Figma with hotwire, of course, but I think there are probably a fair number of content sites and simpler apps that could become simpler this way.

              I might argue that an email client like Hey is probably not a good fit, but I guess it works for them 🤷‍♂️

            2. 1

              I’m not a web dev by profession, but I was under the impression that the issue with generating HTML was the cost on the server. I thought it was a lot easier to scale out by just using a CDN for static assets

              1. 7

                Generating HTML dynamically is of course more expensive than static HTML, but this is how every site in the world worked as of ~5-10 years ago: eBay, Amazon, Yahoo, Google, Wikipedia, slashdot, reddit, dating sites, etc.

                There is a newer crop of apps (that seem to have unified mobile apps) that generate more HTML on the client, and seem to be slow and want me to look at spinny things for long periods. I’m thinking of Doordash and Airbnb, but I haven’t looked in detail at how they work.

                But all the former sites still generate HTML on the server of course, and many new ones do too. This was done with 90’s hardware and 90’s languages. It’s essentially a “solved problem”.

                1. 3

                  The venerable C2 Wiki (a.k.a. the original wiki) switched to being all client-side.💔

                  1. 2

                    And that’s terrible.

                    1. 1

                      Heartbreakingly so.

                  2. 1

                    Only some of the former still render on the server - for example, Google is a mix (Search being partially server-side, pretty much everything else is client-side), new Reddit is all client-side.

                    Everything is slowly trending towards the newer, slower, client-side apps - I guess in an attempt to uphold Page’s Law :-)

                  3. 3

                    That’s sometimes true but usually isn’t. Web dev blogs though often focus on esoteric problems though and gives the illusion that they are more common than they really are.

                    1. 3

                      For Phoenix’s LiveView (and I suspect Hotwire), they don’t actually generate the HTML, but instead pass some minimal data to the frontend which generates the HTML. It acts a bit like a client side application, but the logic is being driven by the backend and the developer doesn’t need to write much Javascript. It’s primarily aimed at replacing client side rendering.

                      You can read this blog post for some details on the underlying data transfer in LiveView.

                      Caveat emptor: I haven’t worked with this tech. I’ve just read a bit about it.

                      1. 2

                        Hotwire explicitly say that they generate the HTML and the client side logic just replaces nodes in the tree. This is why this can technically be used without any specialised backend support.

                        1. 2

                          Thank you for the correction.

                    2. 1

                      Am I missing something or this only works in/with Ruby on Rails?!

                        1. 2

                          The example is Ruby on Rails, their frameworks are written in TypeScript though so they could work for other setups.

                          1. 2

                            It only requires a header and HTML tags. You can even do it manually without much effort, the libraries are only lightweight helpers. AFAIK there are already libraries for Django and Laravel, in addition to the original Rails gem

                          2. 1

                            does anyone know how slow connections or lost connections are handled in Livewire and Liveview? Does the whole site hang? Or can you structure it so only elements of the page become unresponsive/slow?

                            1. 2

                              From https://dockyard.com/blog/2018/12/12/phoenix-liveview-interactive-real-time-apps-no-need-to-write-javascript

                              LiveView … often sends less data than an equivalent client-rendered application. … Thanks to José Valim’s excellent work on LiveEEx, a template language for embedded Elixir capable of computing diffs, we are able to send only the parts of the page which have changed, and we never send the static parts of the template after the initial render. This allows the browser to receive all static and dynamic parts on mount, then only the dynamic parts that have changed on update.

                              So, the only elements on the page that might become slow are the dynamic parts–which is exactly the same as for a fully client-rendered app.

                              1. 1

                                Thank you! I actually think I read his before, but forgot. Sorry to make you do the research for me. But, this is great, you can keep parts static after first render, and then have smaller dynamic elements updating when needed.