Alternatively, web developers could calm down and just write mostly HTML with some plain javascript where warranted.

I've recently done some web development for the first time in 12 years, and I was horrified at all these pointless frameworks that break every usability win web browsers have made in the past 20 years, cost extra bandwidth and have atrocious performance. Like, why? Can web devs really not learn the 4 functions that make up the websockets API? Do they really need a special framework named after a coffee bean?

This kinda crap is why the gmail tab uses a GB of memory.

Tools like htmx aren't the reason the gmail tab uses a GB of memory. You'll find the majority of cases where pages are using way more resources than it should, are due to reasons forced on web developers, like a billion different trackers and several different ad networks, and workarounds to ad blocking to sell more subscriptions, etc.

This is what is so shocking to me when HN spends such an absurd amount of time rallying around this idea that frameworks are the reason sites are bad. Mind you, I do think a lot of them are misused, but 99.9999999% of poor websites aren't because of the framework chosen.

According to my browser, the default view in gmail needs 8.32 MiB of javascript spread over 90 files to render.

While IDLE, the gmail tab uses 10-30% of an M1 CPU core.

That stuff is not down to tracking - it's because the damn thing keeps messing with the DOM, because it has some insane structure where javascript controllers are attached as strings to DOM elements, because it uses about 100 divs to render every row in the list of messages, and because every message is nested literally 15-30 layers deep in a pointless tree of divs.

I am sorry, but web frontend is an insane dumpster fire.

I haven’t tested the following claim and not at the computer atm (^U, see below), but divs must be cheap. They’re just structures which a rendering engine walks through and computes hierarchical offsets of via stylesheets.

I’m not arguing for using hundreds of divs, because that’s a sign of engineering insanity imo, but it’s not a performance issue. You can create a static page with thousands of them and (likely) see that it still doesn’t use 250Mb+ neither idles at 30% cpu core.

Added:

damn thing keeps messing with the DOM … web frontend is an insane dumpster fire.

Totally agree with these parts.

—————

… I just tested 50 div-rows with 200 spans containing numbers from 1 to 199. Total 10k elements, text doesn’t fit on the screen. Bootstrap css+js is imported via CDN.

Mithril.js implementation uses 50Mb of RAM consistently.

A static page with the exact same content uses 71-96Mb depending on the run.

Both use 5-14% cpu when I shake my mouse and 0% when I don’t.

Refresh is significantly faster with Mithril, idk why, probably because static html parser is slow. (Opera, Windows 10, no extensions).

With a single span per row instead of 200 both take 23Mb.

Removing bootstrap from the head inconsistently frees 0-2Mb for both.

maybe they are cheap, maybe not. but lighthouse prints a warning for "excessive number of dom elements" already at 1500...

What browser are you using? Having Gmail open doesn't even use half of a percent of a single core on my machine (Linux, x86, Chromium).

Chrome on an M1 Pro Mac. This is the number that Chrome’s task manager shows me.

I do have a lot of emails, but I think it should only have to worry about 100 of them at a time, so I don’t know why it’s different for me and you. It is possible that my account still receives beta features, because I used to work there, but I remember it being like this for multiple years, since the new gmail came out.

Are you using Chrome through Rosetta? I'm still unable to replicate this on either my desktop or laptop, both of them just idle when I open Gmail and neither will push past 5% usage while I'm opening emails. Your metrics seem a bit odd here.

Same for macOS, Chrome. CPU sometimes jumps to 3%, but that's about it (and I guess that's because it uses slow core).

I have very clean mailbox, though.

Well google use all of their own internal 'frameworks', so you can't really use their web applications to judge the rest of the web.

This used to be true but isn’t anymore. For a while they pushed Angular, nowadays I think a lot of teams are using react. GWT is long deprecated and gone.

I think citation needed on that one.

From what I understand (no special insider information) React is essentially non-existent inside of Google, and NPM is not even available to engineers (be default)

I am not sure how much I can say, because I used to work there. But I think it's OK to say many Google engineers don't particularly like Angular.

It depends what org you're in. Cloud seems to use a lot of Angular, but the rest of the company is coalescing around an in-house framework called Wiz (you can poke around the open sourced jsaction library to get an idea of the design philosophy).

To be fair, gmail was quite great at the time of GWT. Not sure how much use their Clojure “platform” still get, but I think it was very ahead in terms of maintainability of large js code bases (or even ahead as we have it now)

I keep saying the same thing at work on the NextJS / MaterialUI project I’m working on and I largely get blank stares in response.

If you can limit yourself to exactly one, maybe two external deps, which are really just to make your dev life eaiser, you may have something of a point.

You have to remember that a large chunk of "web apps" means "electron apps" which are absolute bloated pieces of junk next to their desktop cousins.

You also have to remember a 'framework' typically doesn't stand in isolation - tens, hundreds, thousands of dependencies typically lurk.

We all agree tracking junk makes it even worse, but the whole thing is already overcomplicated before you get to that point.

> You also have to remember a 'framework' typically doesn't stand in isolation - tens, hundreds, thousands of dependencies typically lurk.

While this is true, at least by having a large number of people commit to the same set of dependencies, you stand a higher chance of complications between those dependencies being ironed out, either directly by the framework maintainers or by the user base of the framework.

> This kinda crap is why the gmail tab uses a GB of memory.

Actually no, and the real reason is organisational.

It has been a pattern for years now for front-end projects to consist of multiple, independent modules developed by separate teams - banking apps are a prime example of this.

Gmail appears to have went the same route, because it now sends over 200 requests when loading - a hallmark of a highly modularized front-end.

The organisational benefit is less knowledge required per developer, which in turn brings other advantages like resistance to turnover.

You can say that about any engineering problem and be right 99% of the time. Because it’s always true, it’s not a super useful analysis.

Somehow, software on embedded, the kernel, graphics, flight control, etc. is all developed by equally large organizations and while they’re far from perfect, they produce far better software than the vast majority of web UX organizations.

Something about web dev is uniquely terrible, in addition to the common factors you mentioned.

I think you judge it like that because errors in UI are usually the most visible.

Meanwhile I can't get my laptop into sleep mode at times because such a seemingly simple feature can't be reliably implemented for some reason and it's been like that for years - that's just one out of many instances of non-web software being terrible.

There's a lot of great software that's not written by people who work with web development. There's also plenty of utter garbage software that's not written by people who work with web development. I don't think web development sticks out enough to make it unique

Gmail is just poorly written. The old version of Gmail was still an SPA, and it was perfectly quick.

Well, get ready for it. GitHub is moving towards React, Next, etc. I bet it will be another disaster like Reddit.

I’m actually happy about how garbage reddit is. I considered installing a redirect plugin to send me to the old.reddit subdomain[1], but ultimately decided I shouldn’t encourage myself to use Reddit, having it load into that dumpster fire of a front end has really helped discourage me from using or interacting with it. I can happily report my reddit usage is at an all time low!

[1] fun fact, you can shorten this to “ol.reddit.com” which is nice because it only requires one hand to touch type “ol.” and get an autocompletion. I always thought reddit was a great name because for right handed users, “redd” could be typed with the hand that would typically stay on the keyboard and would 100% get an autocompletion. Alas, most users are now on mobile.

> I considered installing a redirect plugin to send me to the old.reddit subdomain

I use RES[1] to force the old layout (along with many other things).

1: https://redditenhancementsuite.com/

Where is that setting in res? I was looking but could not find it.

Yeah, I agree - the old version of gmail was perfectly reasonable. But the current version is IMO representative of trends in web dev. Google is both influential and tends to follow the recent trends. Gmail is by no means unique - every web app created in the past few years is the same insane jumble of frameworky js code and a DOM 100 layers deep, just because someone can't be bothered to learn CSS and plain JS.

Google's frontend engineering tends to be pretty poor and out of step with wider industry practice in my experience. They have created not one, but 3 of their own frameworks (Angular, Angular 2 and Polymer), two of which (Angular and Polymer) were rather poorly performing, and the third of which is kinda ok but doesn't seem to be that widely used internally. They tried to create their own frontend language (Dart), which nobody uses.

Meanwhile most of the industry is using React, which is actually pretty well engineered and perfectly fast (you may well find yourself using a slow React app, but that's not React's fault).

P.S. Talking layer of DOM nodes, I actually did a few samples of this the other day. Gmail has 34, which was by far the deepest of any website I checked and probably isn't helping it's performance.

You didn't even mention GWT. I don't know what is causing it, but yeah, Google has dropped some turds over the years.

The original version of GWT was mainly about solving compatibility issues between browsers (of which there were many). Modern GWT/J2CL is all about leveraging the mature Java development tools, especially code completion. GWT can be used with just the standard DOM APIs very effectively these days via the elemental2 library.

Apologies on the slow response.

That makes sense, but I also recall it was about trying to use the same language on the server as the client. And it worked as well as the efforts to use JavaScript is the server. Which is not to say it can't work. There are a lot of traps there, though.

Material Design is also Google’s fault. Regrettably a pretty sizable chunk of the industry either uses it directly or—worse—incorporates elements of it in their design.

I also have a pet peeve with the Roboto font family developed by Google and used everywhere on the web. But I’ll admit that it is a fine font face for its purpose, just very boring and used way too much.

> Talking layer of DOM nodes, I actually did a few samples of this the other day.

Is there a tool for this? I’m kind of wanting to check my site now…

You can run the following snippet in the console:

    function getMaxNestLevel() {
        var i = 1, sel = '* > *'; /* html > body is always present */
        while(document.querySelector(sel)) {
            sel += ' > *';
            i++;
        }
        return i;
    }
    
    console.log('total nodes', document.getElementsByTagName('*').length);
    console.log('max nest level', getMaxNestLevel());

As a side note; iirc the old version of Gmail was the first big scale example of SPAs.

React and Angular are both blazing fast, and are definitely not pointless. Open create react app, spin up a page with 50000 buttons, compare that to a plain js version, then come back and tell us about the atrocious performance.

Apparently you've never heard of event delegation, which has been around for at least twenty years? (I could swear I was using it on IE6, but I might be misremembering.) At any rate, the plain JS way of handling 50,000+ HTML buttons efficiently is a long-solved problem.

https://javascript.info/event-delegation

You appear to be reading more into my post then I intended. The point I was illustrating is that there is no cruft in React.

Try and keep your posts factual.

So you haven't done web development in 12 years, but you're qualified enough to call these frameworks pointless?

I haven't written Java in years so I can tell you with authority that Java 17 is terrible and we should just go back to the good old days of J2EE.

I feel qualified, because I’ve been a SWE for 20 years, have worked in lots of domains (including web, sometime ago) and so I feel I am able to draw comparisons.

Not for nothing, but when I wrote a couple of web apps recently (most recently a market monitoring tool and a physics simulation in wasm and webgl for rendering), I tried different frameworks, but always ended up dropping them. The end result is snappy and fits in kilobytes, and the freaking back button works.

I did of course use some libraries for rendering things like graphviz. I am not a crazy person. But I fail to see what value e.g. react.js* adds, or why there are libraries to wrap websockets.

* For react specifically, I can actually imagine scenarios where it’s useful, but in practice, 95% of places where it’s used should have probably just been HTML with some minor JavaScript for bits of interactivity.

I've also worked as a SWE for many years, and I can tell you hands down that self-rolled frontend codebases are _always_ harder to maintain and add features to, than ones that lean into frameworks and libraries. They are shared understandings that are easily transferrable between contexts.

You don't mention maintainability in your examples, purely things like back button support and disk footprint. They're just pieces in the puzzle.

> This kinda crap is why the gmail tab uses a GB of memory.

It isn’t. Ironically things like memory leaks are why pages use a ton of memory and in my experience everyone coding from scratch results in more of them, not less.

I really don’t agree. When I worked at Google, I filed a couple of bugs for memory leaks in the new gmail, and to my knowledge they still haven’t been addressed two years later, because there are a million dependencies and the thing is so complex no one can debug it, or even come up with a reliable repro.

Memory leaks, like bugs, tend to scale linearly with code size. You better believe your 100k line framework has more leaks than my 1000 line script.

Strong disagree. Frameworks are almost always going to be better profiled, better tested and have more eyes than any home crafted code. The number of lines isn’t really that relevant.

Well, the thing is… for any non trivial web app, you do need a framework (spa or Unpoly like). The question here is if you use an existing one or end up writing your own.

I don’t buy the “just use html, js and css”… giving the same developer skills, without a framework that becomes a mess much sooner than with one. Unless you’re just building a small landing page or todo app.

Unpoly is pretty good, and operates on a slightly different level than htmx, which is all about AJAX. Also, this slideshow is from 2016, when htmx was pretty much unknown.

> Also, this slideshow is from 2016, when htmx was pretty much unknown.

HTMX 0.0.1 was released as "kutty" in May 2020. That was its first release. It wasn't a thing in 2016.

htmx is intercooler.js 2.0

intercooler.js started in 2013

https://github.com/bigskysoftware/intercooler-js/commit/62d3...

>I'm actually very intrigued by the whole "let's take a step back and move a lot of our logic back to the server" approach to modern dev,

What's old is new again.

There's an entire generation of developers now who have no concept of the old world. They started with React/Angular/Vue and have no idea that SSR was the standard default for decades. And now it's a "new idea" that is held up against JS development with no understanding of why and how we got to where we are, and the tradeoffs that were made along the way.

I both agree and disagree with this take.

I started out hand-coding static html pages, graduated to Drupal and Wordpress php stuff circa 2009 (glad that's over!), then worked on a largely server-rendered Rails SAAS in the APM space that I guarantee you've interacted with if you've been in the web game for more than a couple years. These days, I may sling React for my 9-5 but a lot of my personal projects and internal tools are vanilla express apps with very little client-side code.

It's true that a lot of newer devs really don't have a great deal of context for why React & company became the de facto default for building websites and how much we used to get done with largely server-based architectures. I wish we did a better job of teaching fundamentals here rather than bootcamping everyone straight into building SPAs.

However, it's also true that the baseline expectation for web experiences is a lot higher in 2022 than it was in 2009 in terms of the level of responsiveness, interactivity, and overall "app-like-ness", to the point where I think that even with the massive improvements in bandwidth, latency, and web protocols, we still need to accept that there are many cases where just shoving full HTML documents over the wire isn't enough to satisfy user & stakeholder expectations. That's where stuff like LiveView, htmx, and Web Components become interesting to me. The web has evolved, and finally the server-side-application paradigm feels like it's starting to evolve along with it, and these evolutions do feel like they're novel & useful enough to deserve being called "new ideas".

> However, it's also true that the baseline expectation for web experiences is a lot higher in 2022 than it was in 2009 in terms of the level of responsiveness, interactivity, and overall "app-like-ness", to the point where I think that even with the massive improvements in bandwidth, latency, and web protocols...

What? The exact opposite is true: the average web app (including ones like gmail) is far less responsive, slower and heavier than it was 10 years ago. On my M1 Pro, gmail renders at about 20 fps and takes 2-3 seconds to load on gigabit fiber. The web has never been shittier than it is today.

Agree 100%. Also makes me laugh when people talk about server side rendering. Serving a html page isn’t rendering. The fact that a couple of megabytes of JavaScript ever became responsible for making the simplest of pages even display is possibly the worst technology regression I’ve ever seen.

I think 'rendering' here means something like 'doing what's needed to produce the final HTML for the browser to render'. You can produce the final HTML on the server (server side rendering), or the front-end (e.g., via DOM manipulation), or mix them up (e.g., HTMX replacing parts of the DOM with pre-rendered HTML from the server).

i.e., there's two different steps that each do something that can be called 'rendering': templates to HTML, and HTML to what the user sees in their browser.

I'm inclined to agree with the main sentiment of your post though, and lean myself towards solutions that rely on the server heavily with just a splash of javascript on the front end.

> However, it's also true that the baseline expectation for web experiences is a lot higher in 2022 than it was in 2009

Is it?. I think this expected behavior and increased complexity comes more from designers and product owners than from real actual users.

I, as a user, still enjoy a lot more the old Reddit (old.Reddit.com) than the new one. I even prefer hackernews than many other more “modern” forums that feel slow and bloated. And I also prefer the current GitHub to what I bet it will become the moment they start moving it to React.

I like new Reddit’s cards layout when scrolling, but I don’t enjoy its poorer performance and new thread view.

The good bits from new reddit could have been added without heavy JS, since those are just CSS+HTML.

I mean, the broad problem is web performance. I think that client-side rendering is a red herring, and really not the main problem. I think part of that issue is that developers don't spend as much time optimizing performance, because it's less clearly necessary up front.

Web in particular is very hard to optimize for performance just because of its inherent platform limitations. For applications, people expect as-good-as-desktop. But you can't just download a big .exe and install it -- you have to transfer everything over the wire, which is obviously very expensive. So the big optimizations are reducing how much you need to do that. In apps where people click to new pages and do server-roundtrips for interactive data constantly, you can reduce the amount of time your blocked by caching stuff in the browser. For pages which transfer a lot of data, you must use webpack and similar tools to compress and optimize the various bundles.

The second issue is that when people experience slow and annoying websites, it's normally because of ridiculous ad tracking and subscription popups, which are things most web devs don't really care for. But this is also how the web is funded, so you can't just wish it all away. But this is completely unrelated to client-side rendering frameworks.

Another point is it's not like servers are automatically fast. Sure, more powerful than client computers, but also serving many times more people at once. You'll have to do performance optimizations for servers too.

So my main point is that 1. client-side rendering being slow is usually a red herring. and 2. with any site, you should be optimizing performance. That includes both client and server, both of which can be tricky to optimize

And I do think baseline expectations are higher. For example, on old.reddit.com, when I open a post, it opens a new page. When I go back to the post list, the whole page reloads, which takes time (and I'm on a gigabit network). It's a lot faster in new Reddit, where everything happens on the client. At the same time, I'll certainly agree that it's very poorly optimized in many cases. I think there are some memory leaks. It's a solvable problem, though. It's not bad because it's using React; it's bad because they haven't taken the time to optimize its performance.

And talking about GitHub. The new client-side nav is a lot faster for navigating around a codebase than the full page reloads it used to do. It makes sense, that's a huge part of the page you can just leave there. It's a performance optimization to use more client-side rendering in this case, pretty clearly. Fewer round trips to the server (very slow), less data to fetch overall because half the stuff on the page doesn't need to change... etc.

And products like Google Sheets and Google Docs have also really pushed hard on client-side interactive features that were not common 10+ years ago, but are more common today.

And talking about hacker news... here are some problems hacker news has that modern websites typically don't have:

- Form submission weirdness, particularly around the back button

- Have to go to a new page and reload the old page when writing/editing a comment. More round trips to the server.

- Styles are poorly optimized for visibility on both desktop and mobile.

- On mobile, touch targets are very small.

- Form markup is limited and opaque (e.g. most people expect to have a toolbar for rich text options).

Yes "app-like-ness" when that's appropriate. But a lot of the web isn't that. Yet devs / agencies are using a sledgehammer (e.g., React) when a Phillips head screwdriver is what's need.

Users get experiences they don't need (nor want). Site owners gets a maintenance dependency they don't want (nor need).

I think the basic divide is something like "CRUD forms" vs "interactive applications".

I've built basic CRUD forms with ASP.NET MVC. I've built them with Rails. I've built them with React (+ a hundred random libraries). I've also built interactive "apps" in those languages.

Looking back, the amount of "interactivity" that React adds to a CRUD form is NOT worth the added complexity. But! Right now my dayjob is creating an _insanely_ complex app that you could not have done five years ago with Rails (or, like this presentation is about, something like Unpoly).

I think a problem is that React is just more _fun_ to work with than basic server stuff so devs want to work in it. The added complexity is worth it to have more fun. Maybe that's just me, though. I know a lot of people see React as a hammer to hit every nail with, and I was like that for a long time, but I'm starting to come back around to more server-driven use cases for simple sites.

I've been messing with Fresh a lot lately and it's a nice middle ground of defaulting to rendering _most_ stuff on the server, but you can have "islands" of interactivity that get sent to the client as JS. I'm not sure if it will end up gaining traction, but it's pretty nice.

https://fresh.deno.dev/

> CRUD form

This stands out to me as one of the cases very few JS frameworks have gotten right. Remix, with its "all mutations are just form actions" approach, is the only one that stands out to me as having done it well.

I agree with everything you said up to the part about fresh and deno, where it looks like you’re falling in the same trap of those wanting to use react. You don’t even notice it but this is the problem. Always thinking the next shiny tool will solve the problems.

Rails, Lararavel and similar frameworks are great for crud apps. No need for fresh or demo or svelte or next.js for that.

I don't think that Fresh or Deno will solve any problems that aren't already solved. In fact, there are a lot of very frustrating bits about Fresh that worked a lot nicer in i.e. Rails. I would not use Fresh in production right now; if I were making a generic CRUD app I would probably use something a lot easier and with a bigger community around it.

From my experience, this problem is also rooted on designers and product owners.

My own team “modernized” a forum/blog tool used for internal documentation by moving a lot of it to react and SPA architecture and added ton of “app like” features, and I just hate the thing now. The old version, which we still run on some installations, is way, way faster, easier to use, more responsive and more reliable.

But hey, it looks so App-like now…

Sigh…

SPAs solved a labor problem I think. It was the reason that front end development grew so fast.

It is much faster to train people on a combo js+css framework rather than training someone on backend languages, databases, queues, authentication, scaling + html & css for server side rendering.

That seems strange to me as being an "old school" developer I have a lot more trouble trying to get a hang of the new front-end stuff than I do learning a different back-end framework.

But I guess that is just me/generational? Ironically, I feel like there are a lot more job openings for front-end than for back-end now, and I'm much more comfortable on the back-end.

We use SPAs and a pretty strict typescript/react stack. And I still have to know:

Cloud Tech (AWS) which also includes, lambdas, Iam management, dynamoDB, cdk or serverless, API gateway, S3, secret managers etc.

Add to that list the technologies that often get thrown in for extra monitoring testing etc. Jest or mocha/Chai for unit tests. Dynatrace for monitoring. Kibana or something for logs. Some tool for analytics. Github actions for setting up deployment and CI. Maybe you need redis for intermediate caching, etc.

In addition, before you kind of sort of had an intuition of how the data flowed through your basic stack from the database to the web page. Nowadays who the heck knows what's happening. You'll hit some api gateway endpoint which auths through a random lambda who knows where on what server, then it will go hit the actual lambda that holds the function you want to call which may reach out to a database but get intercepted by the redis cache etc etc etc.

Yes modern web dev is definitely much simpler /s.

I see this “AWS for everything” Well-Architected stuff everywhere. AWS benefits greatly from inserting itself in between all our architectural layers.

There’s nothing stopping companies from using the cloud for its primitives (compute and storage), maybe with managed FOSS services (RDS Postgres). We don’t _need_ to go all in on AWS to build a ‘modern’ web application. Yet somehow much of the industry dances to AWS’ tune on how to architect software.

And good luck with having a development environment or even decent end to end/integration testing once you start using all those services.

Architects in my company are required to have aws certificates. They can be monkeys but if they can list a dozen of AWS products and put everything there they are given the keys of everything.

You may work at a company that requires fullstack expertise, but there are plenty of other companies where frontend developers are fully insulated from all those cloud technologies. I'm not sure what your point is here tbh.

A friend of mine moved to a company where they use plain Laravel (with just some sprinkles of js using Alpine) and they deploy to heroku. A team of 10 devs, no systems/devops/Infra and he’s fascinated how well things go and how fast they ship stuff compared to where we worked together before (with all the usual react/redux stuff and an elixir backend on kubernetes)

I wouldn’t say modern web dev is simpler, I just think it is more decoupled. This helps with training for & staffing the more specialized roles that emerged.

Labor wasn't the issue, it was UX.

Users wanted responsive UIs and Gmail showed the power of AJAX in the browser. In the mid-2000s, server power, network latency, and maintaining state were the challenges. The UX was more powerful when the client tracked state, only requested the data it needed, etc.

Things have flipped. SPAs became bloated as abstractions were introduced. Network latency and server power is not an issue anymore. Rendering a bunch of HTML is as quick as rendering JSON.

As a vet of the IE7 days, I love this trend. Leveraging the best of server compute and browsers is going to simplify web app development a LOT.

Ajax was created by Microsoft to show Outlook on the browser....

Not quite what I remember. XMLHttpRequest was invented by Microsoft and used in a outlook webaccess. This was only possible in IE6.

But Ajax is merely a pattern that was enabled by the ‘dynamic html’ that was made possible by having a DOM and JavaScript. It was possible in Netscape years before IE6. I did a production app with Ajax in 1999, using IE4. Before the term Ajax had been coined.

AJAX in early Gmail was a massive improvement. It was mostly hand-coded javascript in a relatively thin page and it was the sweep spot. Today's version of gmail is the most bloated pile of spaghetti framework code imaginable and is far less responsive and usable than the plain HTML version.

Or maybe people don't like waiting for a page to load each time they click a button?

People want responsive interfaces, absolutely. Whether the interface is implemented as full page requests to servers or AJAX requests is irrelevant to users.

Bare AJAX itself almost always will perform better than a full page request, but as you layer on additional requirements, frameworks, libraries, etc. that isn't always true.

I think old reddit and new reddit are a great example of this - both are processing the same data and presenting a very similar UX. But at least for me, the relatively javascript light old reddit interface with full page reloads feels much more responsive and usable than the new site.

IMHO this is a false argument.

Ask yourself: Do "people2 prefer looking at "spinners" or more-or-less animated "page loading..." texts?

Waiting time is the issue, the technology is not.

A server generated page that loads fast beats a Framework-generated page hanging every time!

As for technology:

With "classic" server generated pages "people" will know what is going on (browser indication tht page is loading) and they will know what to do (wait a few seconds at most). With frameworks "people" are left out in the cold with no indication what the problem really is and no apparent remedy or path for solution as a page refresh might interfere with state logic or whatnot bringing totally undesired results.

A lot of dev managers like that they can turn one team into two teams by splitting everyone into front and back end. This makes hiring easier. I cannot emphasize this enough. Easier hiring is a huge deal.

As a secondary effect it also allows for more kingdom expansion. It's much easier to have two teams of five than one team of ten.

That being said, I'd rather manage a team of five good full stack engineers than ten average front/back end engineers. The communication cost of trying to get features out the door with two teams of five is very high.

Then why is every JS-bro "full stack"?

IMO, I think this is a valid question (though asked a bit crudely). To generalize, it's because someone who has done JavaScript programming can point to NodeJS and say, "I'm full stack." Which, while technically true, skates over the reality of NodeJS as a less than ideal backend (see Ryan Dahl and the dawn of Deno). Second, it's more lucrative to bill oneself as "full stack" even if in reality a person isn't. At one point in my career I would have considered myself "full stack". Over time I realized that a "full stack" engineer is a jack-of-all-trades type, which in theory, can be valuable in the right circumstances as an individual doing work alongside non-full-stack engineers. Asking a room full of "full stack" engineers to design and build a product of any complexity above CRUD will naturally lead to a self-sorting of UI/UX and server side engineers.

Exactly. Full stack engineers are sorely needed in every project because they can see the forest from the trees, not because they are experts in everything from botany to carpentry.

As somebody who started in the days of cgi-bin and SSIs, I've lost track of how many wheels I've seen re-invented over the past 25 years. Fortunately I do backend which is at least slightly more stable (modulo the fact that I'm sending more or less opaque-to-me javascript rather than html).

OTOH I have really surprised some PMs by producing a Perl cgi wireframe site during the course of the meeting where we designed the wireframe so we could actually try it. It's a skill more devs should really have in their back pocket.

> What's old is new again.

I work on some old ColdFusion apps.

Some aspects feel very modern.

What’s new is being able to use the same templating on the front and back ends with the same code, libraries, languages, and concepts.

I've tried to use htmx exactly two times. Both times it just ran directly into a brick wall, because it's so limited and has no escape hatch where you can put your own logic. Their solution to this is their half baked new language, which isn't ready, a new language, and seems very much unclear. All they needed was proper hook points.

htmx is focused on hypermedia exchanges in the mode of normal HTML, so client-side stuff is out

it does, however, have an extensive event model to hook into, including pre and post request processing:

https://htmx.org/reference/#events

as well as an extensions API:

https://htmx.org/extensions/#defining

for client side scripting, I think you are talking about hyperscript, which is definitely more speculative than htmx, but I wouldn't call it half baked: a lot of people are using it successfully in production

a less-esoteric alternative would be to use alpine.js, which is similarly embedded but uses plain ol' javascript (and offers reactivity as well, hyperscript is more of a pure event-driven language)

Just checked alpine.js. While it's very nice, was a bit worried about this potentially risky eval use:

    <div x-html="(await axios.get('/some/html/partial')).data">

What's risky about evaluating your own code on your own pages?

The hooks are very limited unfortunately.

can you be more specific?

there are a large number of events

and the extension mechanism has enabled a diverse number of extensions:

https://htmx.org/extensions/

generally I consider htmx to be on the high side of JS libraries when it comes to events and hooks that can be used

I had this same experience. I thought it sounded like an interesting idea, but in practice I didn't think it lived up to some of the hype it often gets on HN.

In my opinion Unpoly does this in a very nice way, with what they call “compilers”.

I think htmx can do the same with built-in events---just not built-in. In fact you may even skip that one today because custom elements are wildly supported since 2020.

More like a hotwire but instead of being extracted from Basecamp's work it feels like it could have been extracted from Makandra's work maintaining many different Rails apps.

I think it's very good and for me, the best of the bunch. I'm moving a very large app to it (from old school RJS) and it seems to have thought of everything that I need.

Just want to point out that unpoly has been around for ages (looks like since 2015). This isn’t a copy of htmx.

Would be interested to know if they stuck with it

Author here. Yes, we stuck with it and evolved the concept into Unpoly 2 and soon Unpoly 3:

http://triskweline.de/unpoly2-slides/ http://triskweline.de/unpoly3-slides/

I'd say 95% of the apps we build are now based on Unpoly, the rest on React.

We now believe SPAs are not a good default for the type of apps we're building. We're still reaching for SPAs when requirements demand high-frequency user input and optimistic rendering, e.g. for a chat or online game.

YMMV!

My problem with liveview IMHO is that it requires an active internet connection and doesn't have offline support, which is a step in the wrong direction in terms of UI performance to me.

It makes sense for a subset of applications that require connectivity but many apps or tools should be able to work offline or without a constant connection.

Livewire is intended to be used where you’d otherwise need to do an API call anyway. It is not intended to handle every single click and toggle and key press. You still do that on the front end, usually with Alpine.

It is a way to avoid writing backend APIs.

If you’re sending every click or every key press then it’s not the tools fault. I agree though, that this should be better explained in their docs.

They said LiveVIEW not LiveWire. Same-ish deal, though.

Oh, sorry. I missed that.

A web application requires connection to the web, which only exists with network connectivity. What you're trying to do is create a desktop application with tools built for the web. Therein lies the problem.

This is not true. Applications only require network connectivity for the initial resources to be downloaded. After that they can be cached, service workers can also be used to provide for offline support. Plenty of applications can run only in the browser and don't need to have a constant connection to a back-end. I can think of a calculator app, where all of the application logic exists on the client in JavaScript, in this case a network connection is an unneeded dependency. But once you build it with a framework like liveview it cannot work without a constant connection.

To me it looks like the opposite. It’s more batteries included, easier to use and has been around for longer. I like htmx too, but too me it’s only better on the marketing side.

The way it componentized the different ‘cards’ or fragements with URL-style lego blocks seems to be the primary novel feature that’s layered on top of HTMLX.

This is already the direction that Remix and Deno’s Fresh framework seem to be taking, at least spiritually. Isolated server-rendered-first approach and only bare minimum JS loaded for fragments/islands that need to be interactive beyond what can be loaded on pageload.

The html attributes vs JSX style templates is really a matter of taste IMO. Although I haven’t used htmlx I get the feeling it would be limiting for more complex cases and involve a lot of hackery or pigeonholing complexity better served by straight up Typscript.

I'd try to optimize logic on the client before moving more logic back to the server. This is essentially what Svelte and SolidJS do - they clean up a lot of the existing overhead of SPA solutions. Of course, rendering server-sent HTML as in the HTMX model (or perhaps HTML generated in-client via WASM) instead of doing costly fine-grained DOM updates could then be added as a further optimization.

I had this going back around late 2000s with jQuery and Spring Web Flow. It was absolutely glorious. Server side declarative navigation (great for dev coordination), seamless transitions, less bandwidth consumed, super simple client side rendering, no more issues with the PRG pattern and user interference, and I even think I put in even listeners to execute animations based on the return fragment.

Never was allowed to put it into prod - "didnt need it". Oh well.