Yeah, perhaps if only there were a structured markup language that could be used to provide this information in an accessible manner with separation of concerns between content and display.
The title is poorly chosen at best and misleading at worst. They’re not abandoning JavaScript, they’re just abandoning client side rendering (angular, etc)
I think the intention was to spark conversation loosely around SPAs vs SSR. It seems we're at yet another turning point and frankly, I'm enjoying the debate.
The back button has evolved alongside SPAs, and users mostly don't expect or want their back button to take them back through the hundreds of small state changes they've caused by interacting naturally with a UI.
Yep. Browsed the slides and then couldn't go back to HN using the back button. Is there a max history depth setting per domain in Chrome? I haven't run into this issue in awhile and forget why it happens.
This is not a website. It's a presentation made with reveal.js framework. This has been made as slides for a talk. It is very much feature that people accidentally don't back out of their presentation while they are doing it.
There’s a browser API for preventing people from leaving pages if they are in a context like that. And unlike this method, it works for the first page, works if you try to close the tab, and works if you try to navigate to a different link. And it doesn’t become entangled with browser navigation.
Well my point is that it's a bit unfair to blame the authors of the presentation for this functionality. Reveal.js is pretty much the standard open-source javascript presentation framework. It's used and developed by slides.com.
I don't know why it works like it does. But mind you this is 6 year old presentation with reveal.js from 2015.
Seems like a half-baked agency-built version of htmx[1], no?
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, but IMO when you need more than statically rendered pages, it should look a lot more like htmx or Phoenix LiveView (if you're using a framework) or something ultra-minimal like Slimvoice[2] if you want to go the bespoke route. Not this.
>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.
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.
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.
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.
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.
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.
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.
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.
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.
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)
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.
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.
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.
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".
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.
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.
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.
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.
> 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 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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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)
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)
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).
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.
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.
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.
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.
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());
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.
> 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.
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.
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.
> 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.
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
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.
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.
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.
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'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.
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.
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.
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)
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.
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.
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.
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.
It's interesting that they appear to plan to use with Rails as a back-end (they mention Rails bindings), as Rails 7 release corresponded with a solution which appears somewhat similar to me, turbo/stimulus. (I want to provide a link to it, but I honestly don't know any great docs for it!)
But I haven't used stimulus/turbo myself. I'd be interested in a compare/contrast between Rails' Stimulus/turbo and "Unpoly" covered here.
There also seem to be a number of other non-Rails-related offerings in this space too. They seem to be really multiplying, which I think shows the exhaustion with JS front ends and desire for things in this space (I am not sure quite what to call it). But I wonder if we can converge on one or two instead of creating more and more. One of the benefits of a popular layer is that you can start building share-able re-usable solutions which compose with it -- you can find lots of solutions for certain things for React, like you used to be able to for JQuery, but splitting between stimulus/unpoly/htmx/etc...
I don't consider a demo app with no docs (that presumably uses stimulus and turbo?) to be anything to close resembling good overview docs on what stimulus and turbo are, but thanks.
While I don't know that I'd go that route to build my own thing when Rails 7 already has turbo_streams and Stimulus I understand wholeheartedly why they'd move away from SPA-for-everything. I can't help but feel that the whole industry is under the spell of React and other single page application frameworks and use them even if other ways would have been faster to build, cheaper to maintain and less complex.
Nice, though it would be nice to eliminate the need to write any JS. I disagree with page 17, I think server side apps could handle those things fine if they were made to support them.
I've been working on a Ruby framework with all the fancy stuff (reactive VDOM, hot reloading, scoped css) but it's 100% server side. Imagine React, but with Ruby and Haml instead of JS, and all logic runs on the server.
The GitHub link can be found in my comment history. It's not ready to be used for anything serious, but I think it's an interesting approach and maybe there is someone who would like to play with it.
At this point web development has become so complex and fast-changing that by the time you're done explaining how everything works the whole world has moved on to the next generation of complexity. We're almost at the point where web development is becoming "unknowable"; like knowing the position of an electron... You can know where it was at some point (maybe) but really the best you can do is estimate its rough position in the cloud.
Is it really worse now though? As a full-stack developer since 2013 (Django on backend since the start, React on frontend since 2015), I think it's finally getting better in the past couple of years, and I think it was worst between 2016-2019...
After years of not knowing what to use because the libraries I've used 2 years ago are no longer maintained or their APIs changed 3 times since then, there's now Next.JS which seems like a well supported, batteries included, opinionated framework with good documentation...
with vite and esbuild on the rise, the days of fiddling with webpack and other complicated build configurations may soon be behind us...,
typescript vs. flow seems to have ended with typescript being the clear winner and having great support in most libraries, frameworks and IDEs... (although I'm a bit scared that the JS native type annotations proposal may again fragment the typing world here...)
browser-side APIs are no longer evolving so rapidly, IE11 & EdgeHTML are dead and there aren't that many features/bugs specific to Firefox/Chrome/Safari anymore...,
Does Nextjs make you use Django less? I think my basic process going forward is going to be Nextjs + something like Supabase as default and only add a more complex backend as needed.
At work we don't have enough manpower*time to convert our React spaghettis to Next.js, but I'm starting to experiment with Next.js & prisma & postgres aside and plan to use it for my next hobby project which I'm never gonna finish just as the rest of them..., If I'm gonna like the approach and not miss some of Django's features right from the start I'm gonna think about letting Django in the past...
Supabase could be enough for a simpler project where you know you won't need any advanced features.., I wouldn't just start with it if I knew the project's gonna get huge in the future, but I did a couple of smaller projects with Firebase alone..
Is it really? I have the exact opposite opinion. I mean, I feel like the industry has pretty well standardized on React in Typescript for the front-end on web apps. Sure, there are other technologies that do different things (e.g. Svelte, and someone else mentioned Phoenix LiveView), but for the standard "I'm building a CRUD-focused web app", there are simple choices to make and it's easy to "do the right thing". I contrast this with 2016, when things were still in flux so it was much easier to make what turned out, in hindsight, to be the "wrong" choice (e.g. Angular or Flow). Plus, tooling support is much better now.
I'd still argue that React is very much the default for new applications where legacy interop or existing team familiarity isn't a factor.
I mean, this is obviously an extreme example, but COBOL is also still used extensively in the enterprise, yes it's still not really used for any new projects.
I would say things are improving. Through WASM we are now getting more languages running in the browser. They are starting to bring alternative frameworks and ways of doing things to the table as well. Instead of this frontend / backend notion, we should start thinking again about the notion of networked applications; like we used to do before the web became a thing.
Inevitably you want some computation to be close to the source data (for efficiency) and some other computation to be close to the point of interaction (for responsiveness). It's not an either / or proposition. You can do both. And phones and browsers can do a lot locally these days. So there's no need to pretend that it is still 1999 in terms of browser capabilities. They can do so much more now.
Instead of AJAX, we now have companies like Tailscale doing all sorts of funky networking stuff in a browser. Likewise, people are running entire 3D games, photo and video editing tools, or design tools like figma, etc. in a browser. All enabled by WASM. Most of that stuff does not involve a whole lot of css, javascript, or html. That stuff is increasingly optional. Browser application development and desktop application development are finally merging after being considered completely separate things for more than 2 decades. It's all just application development. It may or may not involve talking to servers via a network. You don't have to limit yourself to HTTP when doing that.
I think innovation needs to happen in package management. Has it happened yet? Because I don't know for sure, so I am asking because I might have overlooked it.
Even projects from a few months ago can be become unusable unless you are willing to sit down and spend a couple of hours fixing the problem. And don't get me started on packages that have been abandoned altogether but are like glue to functional software.
Innovation isn’t going to prevent people from abandoning projects.
You have to make smart decisions when adding dependencies based on how mature and supported is it. This often means sticking with the big names even if the little project has more hype.
I think it was about breaking up with SPA frameworks/libraries. The whole slideshow is about unpoly which is a JS library which provides SPA like experience without the complexity of a full blown SPA
I'm always interested in ways of building partial page fetches, dropdown menus etc in a way that is thoroughly tested to work well with common screenreaders.
I'd love to see a frontend framework that includes detailed documentation (and ideally video demos) demonstrating how effective their ARIA screenreader stuff is.
Why would the story be different than SPAs? The screenreaders read final html in the browser. It shouldn't matter if comes from server rendered template OR javascript template rendered on the client.
Seems like it depends on how you code the html/templates not how they are rendered?
SPAs very often have terrible accessibility. I think it's important for frameworks that help people build interactive applications (SPA or otherwise) to provide the best possible defaults, plus guidance as to how to use them to build accessible interfaces.
Unpoly takes special care to always move the focus to the next relevant element in an interaction. E.g. when a link updates a fragment, the focus is moved to that fragment. Or when an overlay is closed, focus is returned to the link that originally opened that overlay.
Why can't anybody talk about the fact that HTML was not designed for being dynamic?
Isn't there any format that is a real alternative to HTML, which is truly interactive, lighter than the DOM, use text as a mediu, is multi usage and platform agnostic, can use whatever scripting language, and be easily rendered?
It's not another new format, it's just that a new format is needed to make things simpler.
I have zero patience when it comes to learn angular and its framework model thing. I don't want framework, I want formats and protocols.
I don't even know gopher but something new and fresh and different is really needed. Maybe as long as it's used in a controlled environment for internal/pro software.
Have you tried htmx? Maybe HTML wasn't designed to be dynamic, but IMO htmx does a great job extending it to provide interactivity in a way that feels natural and simple.
HTML wasn’t designed to be dynamic but it certainly evolved to be, and personally I don’t think it’s that bad per se, but modern frameworks such as Angular and React have added so many unnecessary layers of complexity, that most developers have to reason about and work with several layers of abstraction just to make simple things work. There isn’t a real alternative because all the popular modern browsers only fundamentally understand HTML, and have been evolving and refining this over the past three decades or so. What would be nice is to have a new markup that is natively rendered and handled by the browser and that behaves
similar to the document/page model everyone is used to but with built-in persistence, session handling, and dynamic rendering with a very simple and intuitive API. Obviously we have all of these already in one form or another but it’s all just hacked-together HTML/JS/CSS under the hood. Edit: minor corrections because mobile devices suck
Whenever I build something on the web, I can't help but feel like I'm dealing with a word processor. A very advanced one, but nevertheless still a word processor at its heart. Coming from native apps, I despise the idea of text just being out there without a TextView or something.
That’s exactly what it feels like. A word processor distorted into an application development platform. With nearly 30 years of technical debt as well.
This is becoming untenable. The web has only gotten more and more difficult for novice users and developers alike to publish onto. That spells doom for the web in the long run.
I know exactly what you’re talking about from when I transitioned to web dev, but I feel that much less these days with TypeScript (done well) and VS Code. It’s actually a pretty decent experience even if it does feel like a bit of a facade over the top. Once you’ve got all your setup and dependencies sorted of course…
Same here, that is why when coding Web apps, I gladly take the back seat, and although I tend to rant about WebAssembly, I am grateful for it bringing Flash like development back.
No markup format will support interactivity well, you need a full scripting language with all of the standard features.
I don’t think it’s possible to couple the interactivity and visual layout in a single language and have it make sense. We can certainly do better than JavaScript, HTML and CSS but I think there will still need to be at least two languages to describe layout and interactivity.
Nobody cares that you can build up a DOM differently, that's decades old. What matters is: how do changes behave? Your example shows nothing of the complications of lifecycles or state-render loops.
The example above is brief due to forum limitations, so yes, it doesn’t include lifecycles or the whole implementation of a rendering loop. But the context of that comment was using one or more languages for building interactive hierarchies of widgets, and not the topic you brought up, so it didn’t even have to.
Yes and no. That you can build a hierarchy with Element(attrs, children) where attrs may include callbacks is really decades old. Plain JS does it, react and angular do, and also a million template languages.
The question is, how can we not end up in a spaghetti ball? Your scripting style alone brings nothing to the table.
I would look up to something like Elm, which does answer OP's question.
This is on point. The frameworks will always remain crippled due to the underlying platform. Of all the things in the Web Landscape, WebAssembly seemed like a practical move towards what you are speaking about. You can compile Rust/Golang/C++ into a "Web Binary", which in turn can be shipped realtime to clients. However, there's a long way to go, before WebAssembly works as a smooth container environment with better APIs for enhancing the user/dev experience for dynamic apps.
Soon Flutter will have WASM support too, so it'll be a great time. I've been looking into stuff like Iced, Yew, Tauri etc but the multiple client situation for cross platform isn't too great, unlike with Flutter.
432 comments
[ 3.1 ms ] story [ 299 ms ] threadThe back button has evolved alongside SPAs, and users mostly don't expect or want their back button to take them back through the hundreds of small state changes they've caused by interacting naturally with a UI.
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, but IMO when you need more than statically rendered pages, it should look a lot more like htmx or Phoenix LiveView (if you're using a framework) or something ultra-minimal like Slimvoice[2] if you want to go the bespoke route. Not this.
[1] https://htmx.org/.
[2] https://javascript.works-hub.com/learn/a-javascript-free-fro.... https://slimvoice.co/
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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".
Users get experiences they don't need (nor want). Site owners gets a maintenance dependency they don't want (nor need).
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/
Rails, Lararavel and similar frameworks are great for crud apps. No need for fresh or demo or svelte or next.js for that.
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.
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…
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.
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.
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.
The good bits from new reddit could have been added without heavy JS, since those are just CSS+HTML.
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).
I work on some old ColdFusion apps.
Some aspects feel very modern.
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.
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!
HTMX 0.0.1 was released as "kutty" in May 2020. That was its first release. It wasn't a thing in 2016.
intercooler.js started in 2013
https://github.com/bigskysoftware/intercooler-js/commit/62d3...
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.
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.
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 have very clean mailbox, though.
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.
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.
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)
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.
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.
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.
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.
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.
Is there a tool for this? I’m kind of wanting to check my site now…
[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 use RES[1] to force the old layout (along with many other things).
1: https://redditenhancementsuite.com/
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.
https://javascript.info/event-delegation
Try and keep your posts factual.
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.
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.
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.
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.
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.
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.
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 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.
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)
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 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.
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.
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.
Never was allowed to put it into prod - "didnt need it". Oh well.
But I haven't used stimulus/turbo myself. I'd be interested in a compare/contrast between Rails' Stimulus/turbo and "Unpoly" covered here.
There also seem to be a number of other non-Rails-related offerings in this space too. They seem to be really multiplying, which I think shows the exhaustion with JS front ends and desire for things in this space (I am not sure quite what to call it). But I wonder if we can converge on one or two instead of creating more and more. One of the benefits of a popular layer is that you can start building share-able re-usable solutions which compose with it -- you can find lots of solutions for certain things for React, like you used to be able to for JQuery, but splitting between stimulus/unpoly/htmx/etc...
I setup a demo, rails7/mysql[1]/turbo/docker - one command setup you are playing with it. https://github.com/james-ransom/rails7-on-docker-mysql. Give me a star you have a friend for life!
* not Postgres!!
I wonder if there's an update on how Unpoly has worked out for them or anyone else.
The official docs are decent:
https://turbo.hotwired.dev/
https://stimulus.hotwired.dev/
I've been working on a Ruby framework with all the fancy stuff (reactive VDOM, hot reloading, scoped css) but it's 100% server side. Imagine React, but with Ruby and Haml instead of JS, and all logic runs on the server.
The GitHub link can be found in my comment history. It's not ready to be used for anything serious, but I think it's an interesting approach and maybe there is someone who would like to play with it.
After years of not knowing what to use because the libraries I've used 2 years ago are no longer maintained or their APIs changed 3 times since then, there's now Next.JS which seems like a well supported, batteries included, opinionated framework with good documentation...
with vite and esbuild on the rise, the days of fiddling with webpack and other complicated build configurations may soon be behind us...,
typescript vs. flow seems to have ended with typescript being the clear winner and having great support in most libraries, frameworks and IDEs... (although I'm a bit scared that the JS native type annotations proposal may again fragment the typing world here...)
browser-side APIs are no longer evolving so rapidly, IE11 & EdgeHTML are dead and there aren't that many features/bugs specific to Firefox/Chrome/Safari anymore...,
Supabase could be enough for a simpler project where you know you won't need any advanced features.., I wouldn't just start with it if I knew the project's gonna get huge in the future, but I did a couple of smaller projects with Firebase alone..
Is it really? I have the exact opposite opinion. I mean, I feel like the industry has pretty well standardized on React in Typescript for the front-end on web apps. Sure, there are other technologies that do different things (e.g. Svelte, and someone else mentioned Phoenix LiveView), but for the standard "I'm building a CRUD-focused web app", there are simple choices to make and it's easy to "do the right thing". I contrast this with 2016, when things were still in flux so it was much easier to make what turned out, in hindsight, to be the "wrong" choice (e.g. Angular or Flow). Plus, tooling support is much better now.
I mean, this is obviously an extreme example, but COBOL is also still used extensively in the enterprise, yes it's still not really used for any new projects.
React is just utter trash for organisations where maintainability is a concern.
Inevitably you want some computation to be close to the source data (for efficiency) and some other computation to be close to the point of interaction (for responsiveness). It's not an either / or proposition. You can do both. And phones and browsers can do a lot locally these days. So there's no need to pretend that it is still 1999 in terms of browser capabilities. They can do so much more now.
Instead of AJAX, we now have companies like Tailscale doing all sorts of funky networking stuff in a browser. Likewise, people are running entire 3D games, photo and video editing tools, or design tools like figma, etc. in a browser. All enabled by WASM. Most of that stuff does not involve a whole lot of css, javascript, or html. That stuff is increasingly optional. Browser application development and desktop application development are finally merging after being considered completely separate things for more than 2 decades. It's all just application development. It may or may not involve talking to servers via a network. You don't have to limit yourself to HTTP when doing that.
Even projects from a few months ago can be become unusable unless you are willing to sit down and spend a couple of hours fixing the problem. And don't get me started on packages that have been abandoned altogether but are like glue to functional software.
(I am talking about npm)
You have to make smart decisions when adding dependencies based on how mature and supported is it. This often means sticking with the big names even if the little project has more hype.
> Site doesn't load properly with javascript disabled
They should put their money where their mouth is
- Site does not support HTTPS https://triskweline.de/unpoly-rugb/#/ => breaks
There are fourteen competing standards ...
Can you add (2016) to the title? Thanks
I'm always interested in ways of building partial page fetches, dropdown menus etc in a way that is thoroughly tested to work well with common screenreaders.
I'd love to see a frontend framework that includes detailed documentation (and ideally video demos) demonstrating how effective their ARIA screenreader stuff is.
Seems like it depends on how you code the html/templates not how they are rendered?
Unpoly takes special care to always move the focus to the next relevant element in an interaction. E.g. when a link updates a fragment, the focus is moved to that fragment. Or when an overlay is closed, focus is returned to the link that originally opened that overlay.
More details can be found here: http://triskweline.de/unpoly2-slides/#78
Feel free to install a screen reader and play with the demo app (https://demo.unpoly.com/).
The slide said
> DEMO OF SERVER-SIDE APP ISSUES
> Link to demo app (https://demo.unpoly.com/)
> (press Start Classic on first page)
but there is no “Start Classic”?
Isn't there any format that is a real alternative to HTML, which is truly interactive, lighter than the DOM, use text as a mediu, is multi usage and platform agnostic, can use whatever scripting language, and be easily rendered?
It's not another new format, it's just that a new format is needed to make things simpler.
I have zero patience when it comes to learn angular and its framework model thing. I don't want framework, I want formats and protocols.
I don't even know gopher but something new and fresh and different is really needed. Maybe as long as it's used in a controlled environment for internal/pro software.
I also miss Flash.
This is becoming untenable. The web has only gotten more and more difficult for novice users and developers alike to publish onto. That spells doom for the web in the long run.
I wish we had a clear path out of this trap.
I don’t think it’s possible to couple the interactivity and visual layout in a single language and have it make sense. We can certainly do better than JavaScript, HTML and CSS but I think there will still need to be at least two languages to describe layout and interactivity.
The example above is brief due to forum limitations, so yes, it doesn’t include lifecycles or the whole implementation of a rendering loop. But the context of that comment was using one or more languages for building interactive hierarchies of widgets, and not the topic you brought up, so it didn’t even have to.
Am I missing something, or maybe you meant something else?
The question is, how can we not end up in a spaghetti ball? Your scripting style alone brings nothing to the table.
I would look up to something like Elm, which does answer OP's question.
It's a no-html, widget only web framework that's been going for at least 10 years.
https://iced.rs
Btw, client can run rust in WASM, so no reason to keep javascript in there either!
That killed my interest instantly.