I'm slowly coming around to the idea that PageSpeed (or Lighthouse, or Core Web Vitals, or whatever Google has invented this week) is what drives a lot of the complexity in web app dev. People refuse to throw out what they've learned, so every time there's a new metric to chase in case you lose SERPS ranking for being slow! devs heap another layer of complexity on to the Webpack bonfire.
Hydration is an example of this. People chased 'first contentful paint' and 'cumulative layout shift' timings because that's what Google told everyone they needed to optimize for. That meant reducing the amount of upfront work done in JS, pushing some barebones HTML and CSS to the client for those sweet, sweet metrics, and then running a massive bundle of deferred JS to make it do anything. Google is pulling that rug with Time to Interactive, First Input Delay and (coming soon) Interaction to Next Paint, so now devs are trying to write the same website but have the server strip out the code they wrote (eg Remix.run).
Everyone wants a fast website. No one wants a heap of fragile complex build tooling. The answer to the first problem is to stop trying to solve the second problem with MORE TECH. Go back to fundamentals. Just make something that works with with HTML and CSS alone, and enhance it with JS. You don't need to be clever about it, especially if the level of interactivity on your website amounts to basically a form.
One story that comes to mind was when I was still relatively early in my career and the COO of the company came to me asking for some help getting some jquery ui tab widget thingie to work.
And as if the words "COO" and "jquery ui" in the same sentence weren't enough to raise eyebrows, what came next was probably one of the most mind bending software engineering episodes I'd ever witness. It turned out he was trying to put together a web UI for displaying a number of reports from some computationally intensive data warehouse query crunching. We're talking visualization of tables and tables full of data. Conventional wisdom would dictate that implementing this the traditional way would involve query optimizations, various layers of caching, separation of concerns, a framework to manage all the complexity, etc, etc, etc. His approach? Just do the naive queries (slow as they were), print directly to HTML old school PHP style, then save the HTML file to disk.
He was a bubbly happy type of guy and you could see the child-like joy on his face when he showed me how lightning fast the thing would load from navigating from one page to another because it was effectively looking at a static website once the pages had been generated once. I distinctly recall feeling a mix of confused feelings at seeing the guy break every rule in the "programming best practices" book and the undeniably good performance results from the sheer dumb simplicity of the solution.
If the data doesn't change often and there's no further changes on the data after its created, seems perfectly valid. Optimizing queries takes time; in some cases, building new tables for amortizing parts of the computation. And of often you don't know whats worth optimizing till later so its easy to spend a lot of time optimizing the wrong thing.
I mean he basically cached the results for viewing later. As cringy as it seems, it was probably the optimal solution.
personally, I would have probably built out a materialized view and added memcache to generate json to make it easier to refactor additional output formats over time but that's just me. It still wouldn't have loaded as fast as sending a pre-generated html file.
The purpose of the more complicated solutions is to build something that will be maintained for a long time where complexity will grow, and usually, require multiple contributors.
I can bang out a basic landing page site in a few hours that will be extremely performant while pulling in zero libraries. But I would never want to maintain that over any extended period of time or added complexity.
The purpose of more complicated solutions is to prevent devs from becoming bored and leaving.
In my experience, KISS results in the easiest solution to maintain. Then I get a litany of complaints from devs that "this isn't programming" or "this is a dead end to my career" and then they leave. Which paradoxically makes it more difficult to maintain, as I have no maintainers lol.
What are you working on? Without knowing your use-case or what your codebase looks like, I have no idea if the problem is with other devs, or you are just blind to the insanity that is your codebase.
Not saying that latter is the case here, but I've ran into devs maintaining some monstrosity and then complaining about others pushing for off-the-shelf solutions not realizing that nobody wants to spend time learning some bespoke system they created that's not actually as great as they think it is.
You just need to hire older people. I’ve been doing web development for nearly 25 years. I’m at the point where I would love to just babysit some sites while spending more time on my hobbies and more time with my family.
Another poster beat me to it: hire older devs! I'm 42 and my ideal work is maintaining several systems that move rather slowly. It's chill, still responsible, and allows for creativity and inventive solutions when the need calls for it.
Not going to bash younger devs in general but the fact is that getting the job done without thinking of their future career... is usually not high in their list of priorities.
Yep, my personal webpage probably has like a 10/10 score on any performance tracking thing you could find. Because I literally just wrote some html and css, and dropped it into github pages.
I mean, if it really took you a few hours, maybe you actually could throw it away and start again later? Meanwhile, if you have to keep rewriting your setup anyway to account for the new shiny toy everyone insists you use every year, have you really made something that requires less effort to maintain?
Speaking as the TL of Lighthouse and PageSpeed, I can comfortably say that adding complexity is antithetical to our goal. Quality UX and a reliably performant web is what we want for all users.
Ideally, folks would use a thinner stack with _less_ JS, as that's rewarded across all the metrics. But in recent years, many teams build a "site" by building a SPA. As they're entrenched in that dubious decision, the only path to making it performant is adding SSR complexity. ¯\_(ツ)_/¯
Perhaps its the apparent conflict between UX and DX that leads to tooling complexity?
And to nitpick: Core Web Vitals debuted with 3 metrics, one of them being FID. The focus on runtime/JS performance has been there from the start. Regardless, I hard agree on your last paragraph.
> Perhaps its the apparent conflict between UX and DX that leads to tooling complexity?
In theory improved DX leads to improved UX. In practice, subpar/lazy tooling needs to be worked around to get better DX.
I’ve added a lot of JS weight to migrate legacy apps to React always improving time to interactive and responsive error handling/messaging. Vanilla JS and even Jquery just don’t have the DX that allows them to scale in a corporate context (specifically because of under experienced engineers and poor “due dates”).
IMO it’s a lack of initiative from browser developers to move the web forward faster (obvious given the funding comes roughly exclusively from the developers of iOS and Android). I understand the inertia of legacy browsers, but it should not take decades to eliminate the need for these DX polyfills (eg like Jquery took to become redundant, and how long it’s taking React/Vue/Svelte style components).
The whole idea of a "site" full of "pages" doesn't really suit a lot of modern use cases. What do you do when your "app" isn't really a "site" to begin with? Like most of the apps in Google Workspace, or Maps, Earth, etc. It's not their URL structure that gives them value, but the buttload of realtime clientside interactivity enabled by JS.
How are you supposed to "less JS" your way out of that?
The vast majority of SPAs are not 'Maps, Earth, etc.'.
I thought the 'if the level of interactivity basically amounts to a form' of top-level comment sums it up nicely. Many are SPAs for the sake of it, similarly to packaging a website as an 'app' but not doing anything native, offline, or that really warrants it being its own app at all other than getting homescreen space on iOS.
(Totally off-topic: I can't believe Apple still doesn't let you organise that however you want. It's sort of a small thing, but also so in your face, by far the most immediate turn-off to me of iOS.)
Yeah, you're totally right in that complex web "apps" are different to a simple informational page. But do the metrics take that into account? It's just a raw performance score, no, not performance-per-complexity or performance-per-feature etc.?
How do you compare "fast" between "my journal entry today" and "Photoshop on the web" using one set of metrics...?
Applications like you’re describing should consider less DOM and more Canvas API. The apps aren’t documents. They’re more like video games. DOM manipulation and rendering usually degrades performance more than the JavaScript.
They can and should work side by side, along with SVG, WebGL, maybe WASM and workers and such. They are all web technologies. But Javascript is still the thing that controls all of them, their state, URL routing, interaction events, etc.
I spent much of the last few years working on such hybrid apps (DOM mixed with graphics techs, with clientside UI and state combined with server-side with and persistence, etc.).
The DOM has never meaningfully slowed down for me, even with CPU throttling or testing on old laptops. Canvas has, especially in some builds of Firefox. Certainly for rendering graphics canvas or WebGL are better choices, but it's not a performance magic bullet for all apps.
More often than not, the performance bottlenecks are just some bug of ours (a poorly implemented search algorithm) or an unoptimized query somewhere.
No modern web app needs to be just one thing or another. Even if you're operating almost entirely in canvas (like a map) there's still a ton of Javascript (open layers, leaflet, mapbox-gl-js, etc.) that you need, along with being able to use the DOM where it makes sense (reusing buttons, alerts, etc.)
Canvas is also really hard to make responsive. CSS evolved alongside the devices and has first class units for all that. Canvas doesn't have those easy abstractions and having to virtualize your UI without CSS-like helpers (much less things like flexbox or Bootstrap) makes it hard to make standard UIs too. HTML still has its uses for now, though arguably React and other abstractions make it much less important.
And sorry, one more thought: Canvas work can itself be abstracted with frameworks like OpenLayers or PixiJs or Unity. It's a testament to how powerful browsers have become that you can run full MMORPGs or other games in the browser. But that all depends on being able to download a huge Javascript bundle at load time, but then the rest of the experience is usually pretty smooth.
Games and maps are just an extreme version of that, but other examples where clientside DOM apps with heavy JS can still be faster (compared to old school server-side HTML) and easier to work with (compared to canvas) are email, e-commerce, ebooks, dashboards, chat, forums, video tubes, search and filtering, galleries, documentation, project management, etc.
I can see email and chat, sure, but ebooks, forums, video tubes, and documentation? All four of those seem like they shouldn't require much JS, and I would be unsurprised to find good examples of each that work even with JavaScript disabled.
Sorry, the threads got a little confusing here. I think this particular one was discussing those examples in the context of using Canvas vs HTML, with or without Javascript.
> Just make something that works with with HTML and CSS alone, and enhance it with JS. You don't need to be clever about it, especially if the level of interactivity on your website amounts to basically a form.
A big problem with this is that html is extraordinarily limited as a widget framework. You only have a handful of widgets available, and many of them offer very little (if any) customizability from CSS.
For example, say you wanted a checkbox, but you wanted to use a custom shape (Edit: shape - color is more easily controlled today) instead of the browser default. Well, tough luck. From HTML you'll have to put the checkbox inside a label, add an empty span next to it, and from CSS make the checkbox invisible and then get creative with drawing some boxes that look like a checkbox [0] (or, more realistically, load some custom graphics). So, if you're doing all of this effort anyway, why go through the effort of using the HTML input checkbox at all?
I always find it fascinating just how barebones and bad HTML+CSS is as a GUI framework. I really don't understand why people insist it's in any way superior to using a JS toolkit for anything requiring more than the simplest interaction (say, more than a newspaper article).
> For example, say you wanted a checkbox, but you wanted to use a custom color instead of the browser default. Well, tough luck. From HTML you'll have to put the checkbox inside a label, add an empty span next to it, and from CSS make the checkbox invisible and then get creative with drawing some boxes that look like a checkbox [0] (or, more realistically, load some custom graphics). So, if you're doing all of this effort anyway, why go through the effort of using the HTML input checkbox at all?
What the fuck? Just use the actual goddamn checkbox. You can set colors with CSS, but also, it will work in exactly the same way as all the other checkboxes on the user's system. It will respond to keyboard and other input shortcuts the same way as all the other checkboxes they use. It will work with any accessibility devices the user has in the same way as all the other checkboxes they use.
Don't reinvent standard controls just because they're not "customizable" enough. Function is more important than form, and the standard control has a lot more function than you're probably aware of. Also, the user already knows how the one on their system works, because they've already used one hundreds of times.
And the same goes even more so for controls which are more complex than the checkbox. Which is, uh... checks notes... all of them.
The idea that all apps should use some kind of system style that dictates shape for every single control is... Odd. I don't know of any system that operates like this - certainly not Firefox on the Android phone I'm typing this from, nor the Windows box IT wants me to use for work, nor the Linux VM running inside that.
Especially for web apps, writing them so that they look good on every browser with default styling for every element is... Difficult.
Not to mention, users often use the same app from different browsers (laptop, phone, tablet), and are much more easily confused by the different styles of each device and browser than if the app itself is consistent, but different from other apps.
Edit to add: I'm very curious if you can find some major sites that do actually use the default checkbox controls - Google doesn't, YouTube doesn't, Apple doesn't, Wikipedia doesn't, Mozilla doesn't (though I did find a default radio button on their donate page), Microsoft doesn't. Even HN uses plenty of default controls, but still you'll see some custom controls, such as the upvote/downvote buttons.
> The idea that all apps should use some kind of system style that dictates shape for every single control is... Odd. I don't know of any system that operates like this
We came damn close to every OS operating like this in the late 90s. Sadly the future arrived.
I don't think that is actually a good thing. I much rather have people less tied to one particular ecosystem, and preventing barriers to moving from one OS to another.
Instead they get to learn new ways of doing things with every single application they use regardless of platform and still have to deal with platform issues. Yay for progress?
However, they also benefit from innovation in how those widgets work, rather than being locked to historic buttons because the committee can agree on on pixel change a year
By moving from one OS to the other you really mean Windows/OSX/Linux, right? Because thanks to modern web(browsers) you can almost but forget using another one, regardless of someones checkbox design.
"Just compromise your design", surprisingly, isn't a one size fits all solution. Especially when you can implement things yourself. Yes, it's harder than you think, but sometimes it needs to be done.
One of the things that the words "just compromise your design" make clear is that the focus is on the designer, not the users. Which in my view is often the problem. It's especially hollow here given that much of Karellen's point is about what's best for the users.
It is for things like checkboxes. If your design requires checkboxes to be special and different from everyone else's checkboxes, your design is wrong.
Don't reinvent well known controls. Stop doing it. You can give it a border color and an accent color (check out the new accent-color CSS property) and for the rest you leave it alone.
This is completely silly, and no one does this. If I'm going for a square design, I'll want my checkboxes to be square, not rounded squares like Firefox offers for example.
Try to extend this idea to a game menu and see how much sense it really makes to you: would anyone really want default browser checkboxes in an otherwise medieval styled game UI, for example?
Also, if you truly believe that all checkboxes in all apps should look exactly the same (per browser/OS, and except for color), then why not extend this to other aspects of design? Why even allow different sites to use different fonts? That is much harder to adjust to than a different roundness on checkbox corners.
> And the same goes even more so for controls which are more complex than the checkbox.
HTML has a lot of virtually useless controls due to their limited styling. And yeah, sometimes you want custom-looking checkboxes, because you just fucking do and design matters. Also, on some browsers, checkboxes don't even have the lauded accessibility you're thinking about -- I recall a time where zooming in in Chrome wouldn't change the size of checkboxes!
Those aren't even the most egregious examples, to be honest.
> Also, on some browsers, checkboxes don't even have the lauded accessibility you're thinking about
In which case, people with accessibility needs won't be using that browser. And that's the whole point. The user can pick whichever browser works best for them, and implements the standard controls in the way they want. (Or, in the way that sucks the least, out of the browsers available to them.) And if they decide to get a better browser (different engine, or even just a major upgrade to the current one) suddenly all their websites work better. More importantly, they all work better in exactly the same way, so they only have to get used to any differences once, rather than for each and every website.
If you go and write your own version of a standard control which implements it that way you want, you take that away from the user.
HTML allows you to specify the semantics of the controls you want, and have the user-agent bother with the details about how it works. That's going to be more lightweight, more performant, and more user-friendly for more people than any alternative you bodge together yourself.
The best thing about using standard controls for things in that as things get better. You get it for free. The zoom bug gets fixed.
I have a bunch of legacy custom controls I deal with regularly because things like color pickers were not cool enough in 2009. The down side is that in 2022 they regularly break and require dev time to fix so some report that gets run once a year works correctly.
I agree, I know eventually the datalist won't lag on scroll with even just 100 items in their datalist control, and that they'll name their dropdown picker to something other than "-webkit-calendar-picker-indicator" since it's misleading https://jsfiddle.net/klesun/mfgteptf/ If I sound passive it's because I assumed a native control/component would be performant and switched out a lot of controls for it only to have to revert back to a custom solution. But ultimately they will be fixed and it'll happen to us transparently which is nice.
> So, if you're doing all of this effort anyway, why go through the effort of using the HTML input checkbox at all?
Because HTML is the only way to do a checkbox?... Even if you use JavaScript, at the end of the day you'll have to generate HTML for it to render... so then why go through the effort of using JavaScript for a checkbox at all?
And what do you do for more complex, stateful apps? I don't think it's fair to dismiss this problem as "just use HTML and CSS and a sprinkling of vanilla JS". What happens when you need to build anything more complex than a basic form? A dashboard, or web map, or Figma, or Slack, or Gmail, or Gsheets... everything from state to AJAX (and other async) to persistence to URL routing, etc. becomes insanely complex.
I feel like "don't use tooling/frameworks" is the web dev version of "you don't need Java or .NET or WPF or WinForms, just use assembly and gfx drivers and draw pixels on the screen". HTML and ECMAscript evolve very slowly relative to the needs of software businesses, and it would take 30x (if not 300x) as long to write complex apps in those alone. Having a "build and bundle" step is just the webdev version of compiling developer-friendly code (React and frameworks) into the "lowest common denominator" code of browser-parseable HTML + JS.
It's not about "cleverness", but being able to do your job in a reasonable amount of time and effort, vs going back to a 90s-style internet where every page is basically a dumb terminal and all the actual interactivity has to happen on the backend.
I think is a better option is to know your target audience, their expected device and connection speed (metro desktop? rural mobile?) and not to worry about over-optimization. Nobody cares if your website loads in a second if it's so hard to use that it takes THEM more time to do what they need. Better to take 5 seconds to load, and then be actually usable as an app.
FWIW I don't think web apps are getting slower because developers are getting worse, but because the newer frameworks are enabling new use cases that weren't before possible. Photo editing? You used to have to download and install Photoshop, which can take minutes or days depending on your network and connection. Now you can run Photopea in a browser window in a few seconds and do most of the same things.
As for core web vitals? It's not a bad thing to use a performance arms race to get websites to be faster. It forces frameworks to evolve their delivery, caching, loading, hydration mechanisms. But that doesn't have to mean "give up on frameworks and complex apps". It can also just mean keep up with their latest performance improvements, and/or hope that ECMAscript evolves faster, that things like Web Components or PWAs etc. become more commonplace.
The examples you give are a 100% fit for the SPA model. Nobody would build Google Docs or a game from server-side HTML.
That's not the discussion. The discussion is everything except that. The typical example being a CRUD app. A bunch of cards, filters on the left, search box on top, logged in user. It usually isn't much more than that. Which means its low state and lowly interactive.
The problem is that there are a few cases in every CRUD app where it is undeniable that the best user experience would come from client-side rendering. Stuff like password criteria validation, filtering or sorting a column on a table, upvoting or downvoting a post, and other application specific behaviors shouldn’t require a page reload.
What we tried in the jQuery-era was augmenting mostly-server-side apps with components that handled these behaviors. But it wasn’t a good dev experience and it wasn’t a good user experience.
So a lot of teams choose to build entirely in JS nowadays since it leads to a simpler experience to have everything in a React SPA than some things in <dynamic form language of choice> and some things in jQuery.
I’m not saying this is perfect, I think we still have a long ways to go. But I’m optimistic about the current wave of JS tools (Hotwire, Astro, Fresh), and I think “just go back to server side frameworks” isn’t solving any problems.
But not everything is a black or white good/bad fit for an SPA, and you don't always know upfront...
Building a list of blog entries? Sure, it doesn't need to be an SPA. Add a tag filter? Still doesn't. Then you eventually need more complex filters (by author, dates, whatever), plus a text filter, plus thumbnails, plus maybe a gallery view of the photos, and maybe you want all of that with realtime clientside filtering... hmm. You can rip out that part of the static HTML and make it a drop-in widget.
But what if you need to tie that into the logged-in state of the user to determine what they can see? Or you want to integrate comments and facilitate real-time discussions?
Having a split backend/frontend rendering system like that makes it pretty hard to reason about (it's how a lot of PHP sites were built, for example, with serverside HTML and a sprinkling of clientside JS, but coordinating the two gets tough with ugly hacks like using `window` or `data` props to pass variables to the client).
Ecommerce? You can build it entirely backend, entirely frontend, or some hybrid of the two. Look at a random Shopify example: https://nomz.com/ (suggested by their website, not sure if real) and a Next.js example (https://demo.vercel.store/product/quarter-zip). Try browsing around and looking at different products. The Next version is pretty much instantaneous while the Shopify version is slow and requires a full page load for any navigation.
Another example from a decade or so ago was the "real" desktop Gmail vs the light/mobile (and maybe WAP?) versions of Gmail (maybe still available at m.gmail.com). They both did the same basic things, but the desktop version was a lot faster, featureful, and usable once you let it load for 5-10 seconds at first. The light version shows you the inbox really quickly but then subsequent actions (navigating to a message, replying, etc.) are actually slower than the SPA version.
Even for just a moderately complex site, an SPA model can be slower upfront as it downloads a bunch of JS but then faster after that, speeding up all the subsequent interactions (with JSON content loads instead of full HTML pages, auto-detected image sizes, smart prefetches based on state, etc.).
AND it doesn't require a rewrite once your site gets "complex" enough. You can start with a simple SPA that may be overkill at first, but keep growing it organically and adding complexity without dramatically increasing the bundle size (with proper tree shaking, etc.) since the bulk of it was the framework.
With traditional serverside HTML sent to the client, yes a simple individual page may be smaller, but you quickly lose that benefit as you keep sending the header, footer, etc. on every page load, while still needing some sort of JS management system for the interactive parts.
For all but the very simplest site, that means you sacrifice a lot of the developer experience for a minor increase in performance. The user also loses out if you start thinking in terms of "how do I add interactivity to my dumb HTML" instead of "what's the best UI for this".
Safer (and usually better) to just start from an SPA unless you absolutely know upfront your site is going to stay really simple. It's a lot easier to optimize an SPA for better performance than to rewrite a hybrid backend/frontend rendering stack and migrate architectures, etc. (i.e., Jamstack over LEMP/Drupal/Wordpress/Rails)
And what do you do for more complex, stateful apps?
To quote Albert Einstein, "Make everything as simple as possible, but not simpler."
This applies as much to your JavaScript bundler configuration as it does to the origins of the universe. It's not surprising really, because if I say "an instantaneous explosion that causes the entire universe to be filled with matter" you don't know if I'm talking about the Big Bang or Webpack.
> Having a "build and bundle" step is just the webdev version of compiling developer-friendly code (React and frameworks) into the "lowest common denominator" code of browser-parseable HTML + JS.
One problem is that for all the building and bundling webdevs do, only a few very recent frameworks (Svelte and SolidJS) can even manage to compile into something that even approximates "plain vanilla", progressively-enhanced JS on the client. And use of these is still the exception rather than the rule.
Maybe it's because I'm from GenX and from that era but I still don't get why JS frameworks jump through all these hoops just to avoid server-side programming. Why do all these round trip stuff when you could just render it server-side to begin with?
In large part because HTML was not designed as a "streamable" format. The main benefit of AJAX is that it lets you send information back and forth without needing a whole page refresh.
You don't have to load anything to send a request to the server. But when the server sends a response back, HTML by itself can't do anything with it. Interaction isn't really a part of the language. So Javascript needs to act as the client, and take the information to apply some sort of DOM transformation to the HTML so that the user can actually see the response and further interact with it.
Javascript is what allows HTML to be interactive in real time at the component level. There's a lot more of that these days than in the past.
The frameworks still do the same thing, at a higher level of abstraction and with better debugging and less verbosity and manual labor. They make it much quicker to create and maintain complex compositions of stateful components... if that is meaningless, your page probably doesn't need a framework, but a lot of complex sites today are exactly that (compositions of stateful components)
It's possible that may change in the future, like with the Web Components spec. But for now, once Flash was deprecated, JS is the only tool really available to web devs for this sort of usage. It's not that it's the best choice for an interactive web, it's just what history left us with... flawed, slow, clunky, but popular enough as to be worth the costs.
> Time to Interactive, First Input Delay and (coming soon) Interaction to Next Paint
Having worked on one of the most bloated SPAs at Google and doing an SRE rotation to optimize exactly these metrics, I couldn’t agree more on the hypothesis that this is where complexity, jank and fragility arises.
This is why our startup set out to build the best-in-class frontend for cloud computing and making a bet on SSR. I’m from a JavaScript background and personally think hate for the language is undue. V8 is also a marvel of engineering. We elected Go for our application language. It’s faster for our purposes but with SSR the domain language isn’t as important. We could use Haskell if it was fit for the problem domain. We empathize with how ideas such as “user-perceived latency” came about but SSR is a much simpler model and our philosophy is that “simpler is faster is faster”.
The difference is more heuristical than technical.
Render the entire page in one go, rather than have the server render small chunks at a time and have the client patch the DOM. I.e. not having to think about below the fold, adding event handlers to pre-empt and preload. In practice, you’ll need to sprinkle in JavaScript interactivity, but the point is keep this to a bare minimum. See Craigslist or HackerNews.
Simplicity is almost always best, but the hardest part is pushing back on management and product that often only care whether feature requests are possible and aren't as concerned with what goes on under the hood.
Speed and uptime are also features. If customers like speed/uptime (they do) we need to make sure management prioritizes them and understands how certain features will work against speed/uptime.
been a juggling act for me for some time, and always comes down to - they'd rather take a performance hit vs. harm the branding/interactivity. tho we're in a very niche market that doesn't seem to mind (i do my best to make it as efficient as can be)
Cool-looking things appeal to customers, and also to developers.
It's a bit like your car. It takes you from place to place and could drive much faster than speed-limits or traffic-jams allow. But getting from place to place is not all you want. You want to pay extra for the coolest looking fastest wheels you can afford.
When you work with an app or app-development tool that looks cool your self-image improves. You are a cool dude because you work with a cool-looking application. Seriously, it does have an effect on me.
Frontend frameworks often have better developer experience. I want to use one because it’s less annoying to do thing like template HTML with editor completions, than using HTML.
Another theoretical advantage is that you can get better colocation of content, style and functionality.
Basic JS is pretty annoying to write. It reminds me of using goto for control flow. It’s a lot cleaner to be able to put functionality alongside the document structure.
Of course, you can use HTML + CSS + JS but you can also use Assembly for all code. But the end solution here is not Frontend frameworks.
I think it’s time browsers give us a better abstraction to HTML + CSS + JS. Webassembly and friends are nice, but I think the 3 fundamentally need to be replaced together in a performant way such that the simple case of no client side code is well optimised. Frontend frameworks are just a symptom of the problem which is that Web devs have to use the only abstraction creation mechanism available to get nicer development properties.
> Frontend frameworks often have better developer experience. I want to use one because it’s less annoying to do thing like template HTML with editor completions, than using HTML.
Agreed. As I've been developing a service (https://prose.sh) with no javascript and only go templates, the biggest downside is autocomplete.
If you try and tell inexperienced employees this in an interview for a job when you have well over a decade or more of experience—you’re not getting the job.
I agree with you, but there’s some sort of complexity agreement in corporate environments, because people aren’t willing to accept that you don’t need a large build process, or any at all these days, maybe outside of a build pass for JSX.
> If you try and tell inexperienced employees this in an interview for a job when you have well over a decade or more of experience—you’re not getting the job.
Good. An interview is as much you assessing your potential employer as your potential employer assessing you.
I've had clients and self-professed SEO gurus carve out useful content in order to chase that 100 pagespeed score. I wish Google would just come out and state how content vs speed is weighted.
Meanwhile I'm having a ton of fun (and better metrics) by just rendering html from the server and using Unpoly for interactivity and "old style ajax" dynamic updates. And still building the entire application in JavaScript, end to end.
People forget that a form submit is a function call with parameters. The bone of programming; calling functions. Also something something state transfer.
I'm slowly coming around to the idea that PageSpeed (or Lighthouse, or Core Web Vitals, or whatever Google has invented this week) is what drives a lot of the complexity in web app dev. People refuse to throw out what they've learned, so every time there's a new metric to chase in case you lose SERPS ranking for being slow! devs heap another layer of complexity on to the Webpack bonfire.
Hydration is an example of this. People chased 'first contentful paint' and 'cumulative layout shift' timings because that's what Google told everyone they needed to optimize for. That meant reducing the amount of upfront work done in JS, pushing some barebones HTML and CSS to the client for those sweet, sweet metrics, and then running a massive bundle of deferred JS to make it do anything. Google is pulling that rug with Time to Interactive, First Input Delay and (coming soon) Interaction to Next Paint, so now devs are trying to write the same website but have the server strip out the code they wrote (eg Remix.run).
Everyone wants a fast website. No one wants a heap of fragile complex build tooling. The answer to the first problem is to stop trying to solve the second problem with MORE TECH. Go back to fundamentals. Just make something that works with with HTML and CSS alone, and enhance it with JS. You don't need to be clever about it, especially if the level of interactivity on your website amounts to basically a form.