← Back to context

Comment by lwouis

11 hours ago

I like this familly of technologies. Having an SPA-type app that's mostly backend.

Recently i've redone my app website (https://alt-tab.app), and I implemented a minimal spa.js that has a similar approach. I find the end result blazing fast, simple to maintain / reason about, few moving pieces. I used Early Hints, compressed every single thing, inlined CSS, etc. I don't know how i could even make it faster.

I recommend this approach for websites that are not very complex. Of course if i made a browser-based music player with a super dynamic UI, that would have been a different story~

For those of you a similar SPA-type app with more type safety – which is even more useful for writing code with AI – you may want to have a look at the Gleam language and the Lustre web framework [1]. It combines the best of Elixir and Elm. You can mix and match having more logic in the backend or the frontend, as Gleam compiles both to Erlang and to JS.

[1] https://lustre.hexdocs.pm/lustre/server_component.html

  • I really wanted to like Gleam because the Rust-like syntax and static types looked familiar and robust, but seeing how Lustre does HTML templating versus how Phoenix does Heex was my deciding factor to try the latter. My understanding is this is because of a current lack of any macro system.

    I probably didn't give it a fair shake, but it all looks very early days, which isn't for me. Kind of a shame, because the dynamic types are still kind of driving me up the wall in Elixir. Elixir structs and dialyzer type specs feel so much worse than what statically typed languages provide.

Can't the website be literally static HTML for 99% of it? I don't really see any user defined input that would change the output.

It's really fast, and seems fine, but is it just static pages? If not, why not. That's the question most front end devs don't ask themselves enough.

  • I think it seems logical on paper. I tried it, and it feels perceptually way worse. It also think it's objectively slower.

    When you go from HTML page to HTML page without JS, the browser starts from scratch on every page. The user gets a big flash, then the browser has to redraw the page from scratch. It's actually a lot of work often.

    If the browser expected pages to be similar, and added optimizations to reuse existing content, essentially doing internal SPA work, that would be a different story. To my knowledge, the browser does no such optimization, and brute-forces renders every URL from scratch.

    You can actually try for yourself on the website I linked. Chrome devtools > disable Javascript. It's a pretty good experience still since I optimized everything. However, you see all sorts of things flicker and move around. It's not the smoothest experience. And If you have worse Internet, it gets worse and worse as you see more of the tear-down > built-up on every click. With the SPA experience, if you have bad internet, you can still scroll around and use the page, as you wait for the update to arrive.

    Of course, you're totally right that static HTML works pretty good when the website is already simple and fast. My point was that with 4KB-uncompressed / 140LoC, I can get the smoothest experience. And I unlock options later on like having loading spinners for example.

    My general point was that you can do simple client-side rendering in 140 LoC. You keep a simple backend-served website, and add a little polish this way to have a smooth experience.

    I find it very cool to have polished app-like experience, while having a simple backend to serve. I like the low-tech, few moving pieces, yet I get options for great UX if I want.

    I got charmed by this path with LiveView and Hotwire back in the day. I'm thankful that people continue to push this approach. It's wonderful

  • > I don't really see any user defined input that would change the output.

    I feel like the distinction between static websites and SPAs has been lost in the last decade, despite it being in the name _single page application_.

    The point of SPAs is not "it's more interactive than a static website is", but "I don't need to fetch the new page and wait it to load as I navigate". You can have any custom behavior just by adding JavaScript. That's something we have from 30+ years.

    "applications" don't interrupt the user as you navigate, and we tried to replicate that on the browser, by having history and render JavaScript controlled.

    • > each navigation had to reload the whole page

      Saving the world, 50ms at a time.

      Honestly there are times when using the View Transition API makes sense, but the context here is a dinky brochure site. The weight of scripting does as much damage to first load as it saves on subsequent loads. Browsers are good enough at managing this stuff themselves.

Dude thank you for making AltTab. Recently you've introduced the pro version and paywalled some features behind it. That's totally fine and I bought the pro version but my honest 2c for you is...25 bucks for a window switcher app seems too high. Please make it 15 or less. Thanks