It's much better than people make it out to be.

I don't understand this.

Frontend dev is about writing a portable software to run on as many runtimes as there are users. There is literally nothing to prevent any frontend software, good or bad, to "scale", because scaling in terms of users is nonsical for frontend dev (unless you consider browser compatibility as scaling, to which statement I'm orthogonal).

Note: meanwhile, back end dev is about writing a program that accepts as many users as possible, which make front and back nicely yin-yang together. But maybe I'm overstating things here :shrug:

I read your comment as assuming that the division between the server's job and the client's job is fixed, but as the browser has become more powerful many things have moved to the client.

So now I have to convert CSV, for which there's no official specification, to JSON, and then make (up to) 1,000 HTTP requests via HTTP 1.1 -- and a different back end team owns rate limiting for all ingress. I end up using a package called 'promise-limit' to ensure only N number of requests are open at a time; firing 1,000 simultaneous XMLHttpRequests is a bad idea. I end up fielding bug reports concerning the translation to JSON for edge cases. And collating the 1,000 network responses for any individual record that failed to persist was something we didn't get to building. So users were uploading 1M records, had some proportion fail, and had 0 visibility into what data the system had, and what data didn't make it.

Eventually, we gutted all of that and the backend team added a file upload endpoint. But explaining why this shouldn't be a front end feature, to folks who primarily or exclusively do backend work, it's tough to communicate (1) all the pain points of dealing with the complexity in the front end and (2) the scalability issues. "Can't you just do it on the front end" is such a frequent retort I receive, for things we truthfully should do on the backend.

It’s often tempting to model URLs like database entries and send multiple requests to the server to model updating many records based on one action. That’s a mistake - have the client name the action, send one http request, and execute it in a single database transaction in the backend if you need to. This approach is way more reliable, debuggable and consistent. This sort of thing is absolutely the backend’s responsibility.

I've also found that it results in a non responsive webpage. For instance, text taking multiple seconds to render in an input box (Slack, Facebook, amongst others) and times where the browser tab process ends up allocating a signficant percentage of system resident memory and/or CPU resources, which makes the computer itself slow to respond.

Spitting out html from the server is incredibly easy to scale.

while code may move to the frontend, the notion of scaling isn't a function of the number of users (as the original op erroneously states).

maybe they meant their front end code scales as complexity is moved from server to client? that would make sense.

https://infrequently.org/2021/03/the-performance-inequality-...

More context in older post:

https://infrequently.org/2017/10/can-you-afford-it-real-worl...

> Partner meetings are illuminating. We get a strong sense for how bad site performance is going to be based on the percentage of engineering leads, PMs, and decision makers carrying high-end phones which they primarily use in urban areas.

And yes, that makes a difference, you can deliver more features, faster, more reliably.

But, if those sites just bog down and take double-digit seconds to load, even when properly deployed on scaleable delivery architectures, with fiber-optic speeds, and CAD/gamer-level power machines, they are junk.

And I increasingly see exactly this junk been over the last few years. Even (and often especially) the major sites are worse than ever. For example, on the above setup, I've reverted Gmail to the HTML-only version to get some semblance of performance.

Sure, some of this could be related to Firefox' developments to isolate tabs and not reuse code across local containers and sessions, but expecting to get away with shipping steaming piles of cruft because you expect most of it will be pre-cached is no excuse.

Your site might have the look and features of a Ferrari, but if it has the weight of a loaded dump truck, it will still suck. If you are not testing and requiring good performance on a rural DSL line and mid-level laptop (or similar example of constrained performance), you are doing it wrong.

My head hurts just thinking about react.

But that is just the beginning of the process, the job is barely half done.

The devs must then focus on exactly what is needed in the code to refactor and strip out every unnecessary instruction and byte of download.

Page load times and refresh times that are more than 3-digit milliseconds rapidly become unusable. When it is 5-dicit milliseconds, on a modest machine, you are shipping junk, and should not consider yourself a developer. Amateurs can do better.

Wow, do I miss the days of the 5KB web page competitions...

The idea is that these libs and framework make an honest attempt at making web apps. Also well intentioned but wide off the mark. Most people access the internet through mobile phones[1] with dodgy broadband connectivity, hence don't need an app running inside another app - do you understand the redundancy and the pitfalls of janky, horrible UIs for the marginal performance improvement? Or the famous It doesn't reload the whole page...very few people actually care about.

If you are building the next instagram, go right ahead and use bleeding edge js frameworks, but not every site/blog needs to be an app.

[1] https://gs.statcounter.com/platform-market-share/desktop-mob...

Except that I'm not even sure that the next Instagram or whatever should be a web app - it should be a native app.

I saw the beginning of the "write once - run anywhere" concept decades ago. Sounded fantastic. Yet here we are and it is more like "write once - stumble and crawl someplace".

It is most discouraging that many major houses do it so badly, and even their native apps are similar bloatware...

> Debugging modern front-end code is a breeze

Is still hit or miss every once and while depending on the use case. For example debugging service workers is still a bit of a nightmare. And I've also had some issues debugging a chrome extension written with Vue CLI + the browser extension plugin.

First, you are basically breaking the concept of the web, a collection of documents, not a collection of code that must be executed to get a document. That has many bad effects.

Browsing is slower, you have to download the code of the whole application and wait for it to execute other API calls to the server before the page is usable. That can take a couple of seconds, or even more on slower connections. With the old pages rendered server side not only you didn't have this effect, but also the browser could start to render the page even it was not fully received (since HTML can be parsed streamed). Not everyone has a fast connection available at all time, and it's frustrating when you have only a 2G network available and you cannot do basically anything on the modern internet.

It's less secure, since you are forcing the user to execute some code on its machine just to look at an article in a blog. And JavaScript engines in browsers are one of the most common source of exploits, given their complexity. Also JavaScript can access information that can fingerprint your browser to track you, without particular permissions. Ideally in a sane world most of the websites don't require JavaScript, and the browser would show you a popup to allow the website to execute code (just like they as you access to the camera).

It breaks any other tools that are not a browser. In the old days you could download with wget entire sites on your hard driver to consult them offline, with "modern" SPA is impossible. Of course that implies that it breaks things like the Wayback machine and thus history is not preserved. And serach engines penalizes sites that are not a clean static HTML.

It's also less accessible, since most SPA don't respect the semantic of HTML, everything is a div in a div in a div. And of course you still need a browser, while with HTML documents you could process them with any software (why a blind person need to render the page in a browser? While a screen reader could have simply parsed the HTML of the page without rendering it on screen...). It breaks navigation in browser, the back button no longer works as you expect, reloading a page could have strange effects, and so on. I can't reliably look at the address bar to know the page I'm in.

Finally it's less robust. SPA are a single point of failure. If anything goes wrong the whole site stops working. While a bug on a page on a classical server side rendered website breaks only that particular page. Also error handling is not present on most SPA, for example what happens if an HTTP request fails? Who knows. Look at submitting a form, most of the time there is no feedback. On a classical server side rendered application if I submit a form I either get a response from the server, or the browser informs me that request had failed and I can submit the form again.

I think this ship has sailed a long time ago. Nevertheless, I still think that current SPA frameworks are overblown. I am partial to Javascript/HTML + WebComponents. However, I put the blame into the influx of "coderz" that in the last 10 years have arrived to do FrontEnd development.

It is very similar to the use of thick frameworks in the backend (LoopBack, Ruby on Rails, etc): There's people who do not have a clue about what they are doing but they still build SPA websites by changing some code here and there after an "npm create-react-app-shopping-cart" script.

I've interviewed hundreds of "Frontend Developers" and for the majority of them, once you start entering into the concepts of HTTP headers, why do we have CSS? why do we use font-icons and image sprites, CDN, JavaScript closures, JavaScript this/that issues, let/var differences, etc, they stare me with blank eyes.

2G is being phased out (at least where I live), it no longer works here. Chromium browsers have a slow-3g network effect to test your code/sites. I use it frequently. Sometimes it reveals problems, other times it's a shrug. Some features just require bandwidth and there is no reasonable way to avoid it. I do try to reduce page weight as much as I reasonably can.

Lots of features of the modern browser will leak finger-printable information. The JS engine is hardly the only problem piece. I guess your general complaint here is to indicate the world is insane. I tend to agree, but I don't think this is the principle reason why :)

Screen readers are notoriously difficult to make work correctly. In my experience, this is a universal issue with the web generally and isn't unique to SPAs. If we're serious about audio accessibility we need an actual standard instead of this guesswork.

Breaking navigation is a pet peeve of mine too, poorly behaved front-end routers are terrible. I always target working urls into any part of the app as refreshing the page is a common operation. And I must have a properly functioning back/forward for my own sanity in development if nothing else.

I will beg to differ on the point of failure. SPAs can also be apps, paired with a service worker and a local data set they can continue to function even if you are completely offline, or the server is completely offline. Obviously if your web app is just broken, yeah, nothing's going to work. But in the case of SSR, that's also true if your network is down (locally or remotely), or the server is down/broken.

A well built offline-first SPA will reduce the total number of single point failures that kill all functionality. Also, offline-first SPAs have the side effect of masking some of the latency over a slow 3G link - which can improve the user experience significantly.

Is actually one of the symptoms of the issue at large I think.

I understand some sites depend on more complex APIs and such - certainly fbook uses the complex stuff that these frameworks do..

However many people are using wordpress and similar tools simply to have a basic static few bits of info from a few pages display decently on various devices. I too am guilty of such a thing on more than one occasion.

For these cases I am moving towards converting the designs to static html and using a php based script from coffeecup to handle the contact form part that in the past I've lazily just added a two click plugin from wordpress to handle.

I feel that the CSS standards group really dropped the ball with not having better responsive menus 'built in' as a part of the problem that can be solved in the future. Now that grids are built in - the menus that bootstrap does auto-magically for most devices is the missing piece that keeps many sites from being just html/css.

I'd love to go back to netobjects fusion for design, but it has not kept up with the responsive needs of the web. I tried coffeecups site designer in beta and it wasn't for me. I've built dozens of sites using notepad++ and occasionally load up sublimetext for find/replace - but still feel that more visual / wysiwyg type stuff is greatly desired by much of the world.

Wordpress is going more in that design direction as the gutenburg blocks start to work with full site design and not just page content. And I still keep meaning to take the time to try out pinegrow site builder - as that might be the replacement for netobjects that I've longed for.

But it's not just me - there are plenty of people who could / would make a site and find things too complex today - about 7 years ago I found someone in the top 3 search results for a home service - and inquired about their designer / seo .. The guy who was there doing the work told me he made the page in microsoft publisher.

While I'm not advocating for the bloat that Msoft's frontpage pushed into the world, and I know the time of clearpixel alignment is a distant memory, even though we have an infinite amount of tools - it still seems the front end world is more complex than it needs to be.

It is better in some ways and worse in others. I hope CSS gets better menu options so there can be less pieces needed for a decent puzzle. I like non-js sites just fine, and building with less tools is okay too.

I think people are forgetting how bad it used to be. Loads of jquery spaghetti code everywhere rerendering the page 1000 times with a nested for loop.

Also, web applications have became so much more complex than they were (but still work!). Things like Figma would be unthinkable even a few years ago. And - even though it's running in a browser Figma feels far more responsive than Illustrator or Fireworks (RIP), plus it has a load of collaboration tools which these desktop apps don't have.

Websites have no reason to use JavaScript. They should be a collection of documents, possibly generate dynamically on the server side, but to the user HTML+CSS that can be viewed in a browser, downloaded with curl, viewed as source code, etc.

Web applications have no reason to exist. Basically we are turning the browser into a JVM, a way to run code portably. But this have nothing to do with the web! It's just bytecode loaded from a remote server. What Figma, or GMail, or Google Docs has to do with a website? Nothing.

These things shouldn't be implemented in a browser, it's not the right place. These problem should have been solved at the operating system level, but it was too difficult for Microsoft to agree with Apple and the open source world on a portable operating system interface to made possible universal binaries among platforms, with maybe a bytecode, maybe a way to load code from an URL.

No they couldn't agree, so they took the only really open standard, the web, and bloated it, basically making it an operating system (well, Google even made it really one!), what's the point? That now most people run Windows or macOS with on top a browser (probably Chrome) into which they run 95% of the software that they use. Does this make sense? To me is a huge inefficiency, that only makes things slower, slower than they were in the 90s to me (even if we have order of magnitude more powerful hardware using the GMail web interface feels slower than what it was using Outlook on Windows 98).

Put another way: "websites have no reason to execute code". Is a document with an embedded form a website or a webapp? what if one of the inputs is custom and requires some custom validation logic is the expectation from your train of thought that this logic must only execute on the backend?

Websites are interactive documents and they have been since the inception of the hyperlink. I struggle to draw a line where a website becomes a web app outside of the obvious examples at far ends of the spectrum.

Although you probably (?) want to add that OS maintainers are slowly turning their repository of available OS-level applications into walled gardens, which I could see may push some developers to currently prefer web application implementations.

In the same way that writing a REST API is "connecting to some DB and simply exposing data via some endpoints" or building a machine learning model is "simply throwing some data at some algorithm and getting a bunch of analysis out" or devops is "simply starting some remote servers" or creating an OS is "simply writing a bootloader and then some stuff on top."

Remember, my comment was a response to the claim that something like Figma could not be done before the current frontend development complexity mania. But there is nothing in that collection of bad tools that is necessary to write a canvas based UI like that. It could have been done before and it most likely has been done before.

I think this is the important thing here. Everything feels less stable, and more prone to breaking, on the modern web. You write some simple HTML, style it with CSS, and write vanilla JS for the parts that need it, and everything feels solid. You start a new project with a framework, and it seems like there is this whole area of your project that is essentially a black box, ready to break (or misbehave) any time.

IMHO, a lot of frameworks just add extra complexity. Now that we're in the twenties, you don't need nearly the level of browser compatability shims like at the turn of the century. Sure, bleeding edge features need that, but most sites don't need any of that. Certainly news and shopping fit well enough with turn of the century browsers, so everything else is fluff (and retargetting, ugh).

It's the same with a lot of server side frameworks; especially PHP frameworks. I've never been able to grasp what a PHP framework can do that PHP can't, other than burn 50ms of cpu before outputting anything.

Any framework you're not familiar with will feel like this. This isn't something unique to frontend frameworks.

But the frameworks get out of fashion faster than you can obtain deep knowledge of them.

However, both front-end and back-end are substantial enough now and have enough frameworks and environments that it's really hard to do well at both. I'd much prefer more specialization, which would hopefully lead to higher quality.

in my circles more and more people look at svelte to try to get away from frameworks altogether.

new tooling is always just around the corner: there is a webpack killer annonced every couple of months.

this very site is full articles "why we switched from/to react", etc.

in the javascript community "stability" is anything with a bit less churn than the bleeding edge. i think it will result in a massive burnout for a whole generation of developers.

Regardless without a framework it ends up with you reinventing core framework features anyway. Yes, a framework driven app is more complex if the page/app is extremely simple. But if it is of any complexity a framework driven app is going to be far easier to maintain and reason about in 99% of situations.

Give me basic templating and server-side rendering and I'm good to go.

That was a time before the web became more standardized as an app platform. Corporations like Microsoft with .NET, Sun with Java, and Adobe with Flash, were all competing take over the whole world of write-once-run-anywhere frontend apps, become the platform of choice, and lock everyone into their way of doing things. Also there was no distinction between desktop computing and mobile computing as mobile computing back then was still underdeveloped.

Now the web is the frontend platform of choice. Ostensibly the platform isn't owned by anyone but the WC3 consortium (which is good), but practically speaking, Google won since everything is WebKit now (which is worrisome). And this has not yet so far solved the problem of the web being built on an incredibly poor programming model that make everyone want to use virtual-DOM frameworks and CSS preprocessors.

Hopefully, web assembly will replace the status quo and let people develop front-end apps using better programming languages and frameworks than just the ones the compile to JavaScript.

Bootstrap + jQuery on the front end, Flask or similar with CherryPy on the backend. SQLite or Postgres if you need it. That will handle 99.9% of websites, it will be cheap and easy to develop and host, and deliver a great experience to the end user.

Why? CSS can do layout with grids and flexboxes just fine, while es6 plus the modern browser api are as ergonomic as jquery. Why pull these dependencies from a decade ago?

I never bothered to learn CSS is why. Bootstrap looks good and consistent with what users expect and requires almost zero effort to use.

Now 1 component will be: server side html, client side html, css and js.

Nice generalization. Tell to that to the thousands of absolutely massive companies running on server-rendered HTML how they need to adopt cutting edge JS.

A good analogy I think is any person using MS publisher to create a book layout. Sure it can be done quickly because the software does the thinking; but should it? Good books have skilled typographers designing the proportions of the pages relative to text block, the fonts, et cetera. The end result is a book that one scarcely notices but feels very pleasant to hold and experience.

We need websites that are subservient to their content; sites we scarcely notice but thoroughly enjoy.

EDIT: one last point: I think part of the problem is also that browsers have an identity issue. E.G. they started as a static publishing platform, but now they are a full blown operating system with web assembly etc. As we know, anything that does too many things is inherently complex, and hence “bloated.”

You can make a SPA that's a joy to use and loads and runs extremely fast. Hardware has never been faster; browsers and application frameworks have never been as good as this (I'm talking about the web stack). It's really nothing to do with the tools or technologies that marketing insists it needs mixpanel, GTM, optimizely, hotjar, FB pixel, smooch, and god knows whatever else in order to do its job effectively.

But then, with Angular/React/etc, you now not only have 1 project on your hands but 2 different projects that must be compatible: the backend and the frontend. These 2 different projects ought to be in 2 different languages, unless you are developing backend in JS too - maybe there's even an ORM that can generate migrations these days for NodeJS ! But that wasn't the case last time I checked, also loosing the ability to have server side rendering without the additional effort of deploying a rendering server with all that comes with it.

People ditched jQuery saying that vanilla JS was just fine, but it turned out not to be quite the case so there are still releases of jQuery, and at the same time NodeJS was released and npm and then Angular/React/etc which in my opinion created with two goals in mind 0. having OO components for GUI dev and 1. offer IoC to overcome the difficulty of dealing with custom component lifecycle like in jQuery which leaves you to monitor the DOM and instantiate / destroy each plugin by yourself. Idk if there are other reasons, but it seems to me that apart from that, that DHTML is still pretty much the same: you're adding some logic to change tags and attributes, anyway.

Today we have a chance to break these silos again with the Web Components and ESM browser feature and W3C standard because it does solves elegantly the problems that React/etc seemed to be designed for and do no impose a frontend framework, you can just load the script in your page and start using <custom-tag your-option=...>... The browser will manage the Component lifecycle efficiently, and devs can use it in their templates without having to load a framework so everybody wins.

This is also a chance to simplify our code, levitate by throwing away dependencies. Of course if you want to do full client side navigation with an API backend you still can, but you can make generic components that you will also be able to reuse in other projects that do not use a particular framework. You need no tool to make a web component, this is an example of a jquery plugin that was ported to a web component which has no dependency, with browser tests in Python: https://yourlabs.io/oss/autocomplete-light/-/blob/master/aut...

Webpack does a lot, still slow for development be we're seeing the light with Snowpack and esbuild, allowing to have webpack in production only (ie. to generate a bundle in Dockerfile) and benefit from actually instant reload thanks to ESM.

So if you go for web components and snowpack, you get an extremely lightweight toolkit which I love that will work for every page that's not an overly complicated web app. But then I thought I actually don't have so much frontend code, it would be nice to have it along with the backend code, so we went for a python->js transpiler to develop web components in pure python which also replace templates, it was surprisingly fast to implement: https://yourlabs.io/oss/ryzom#javascript

Is this improving the situation or not depends on your POV, heck I'd understand if you even hold it against me, but the frontend development tooling is still evolving for sure, and I can see how the browsers are doing efforts (except Safari) to simplify DHTML development, because:

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.” – C.A.R. Hoare, The 1980 ACM Turing Award Lecture

This setup is described in more detail in single-spa's documentation.

Suppose your base Design System is web components. Most Microfrontend (MFE) teams will still pick up an off-the-shelf React, Vue, Angular, etc.

But VDOM and web components don't always play nicely. If you have Parent-Child web components, specifically 1 parent with N-immediate children, React can't resolve this gracefully. Every render past the first breaks with Stencil. That's a pretty significant issue, because (very) common components like Select dropdowns are modeled as 1 parent with N immediate children.

So you can't any longer stay in React's declarative model. The workaround (last comment in issue) has you writing imperative code to fix the problem.

It has that "using D3 in React" vibe to it. It works, but it's not nearly as elegant as if you had, say, a React-based Design System (but then, of course, all your MFE teams must use React).

https://github.com/ionic-team/stencil/issues/2259

Users have also reported the same analogous issue exists for using Web Components in Vue too, so it's not even a React-specific shortcoming.

https://github.com/ionic-team/stencil/issues/2259#issuecomme...

Are they? I'm skeptical we can know that for any given website; specifically, accessibility is a huge pain point for so many sites, and it would seem difficult to know how many people are turned away from a site because it isn't set up to serve them.