So far I haven't met a user who asked for ads, unmuted autoplaying videos, popups, tracking, loading screens, and UI that's basically broken by design. Did Google really redesign Google Images' UI due to popular demand? I doubt it, because the new one only works 80% of the time when I try to use it.
Most websites that are obviously built using modern frameworks and shiny layouts don't let me open links in new tabs, not to mention they're a nightmare for screenreaders and similar tools. And considering how often terms like "responsive" are thrown around it is staggering how easy it is to break many of those sites just by resizing the browser window.
In some aspects I'm definitely not the typical user, but to quote Adam Jensen: I never asked for this.
By voting with their feet in favor of free ad-supported services, they are essentially asking for ads.
Perhaps this will change in the future. Twitter is said to be experimenting with offering subscriptions, akin to what Substack or media companies do. But the general arc of the internet up until now has been toward free-with-ads.
Supposedly one-page apps are meant to improve latency and interactivity, but FB is slow as molasses and frustrating regardless.
As for FB's slowness, SPAs are hard to do well when you have a lot of live data all over the page. You can get clever with optimistic backend calls and caching, but in the end you still have frequent state changes.
Users want infinite scroll to be fast, so you need over-eager loading _in case_ they scroll. Add over-eager loading all over the page (in case they click on a user profile, in case they click on FB Marketplace, etc.) and you have a recipe for a CPU hog.
Historically, the Web started out as hypertext: static text documents which were interlinked. But right off the bat, there was this drive to create "Rich Web Applications": the browser as an alternate to applications which you don't need to install on a "gatekept" operating system (Windows and OSX).
Flash, Silverlight, Java Web Applets,... All those browser plugins were exactly meant to achieve this. But none of them quite fully lived up to the potential of the idea.
There's a good reason why Microsoft in the 90's wanted to dominate the browser market: because it was a potential threat to lose control over what users could or couldn't do with their computers.
Things changed when mobile devices landed, and Google jumped into the browser market. Suddenly, building a web experience no longer wasn't as "trivial" as making sure your CSS worked on Explorer, Safari and Firefox.
At the same time, the "Application Wars" moved into the mobile realm where there was this battle between "native applications" and "web based applications". The latter was the notion that you could get the same functionality without having to install an app from an app store on your device.
Those dynamics of competition were - and still are - a driving force behind innovation that made browser engines ever more powerful and complex.
"Front-end" as a dedicate discipline didn't truly exist before the 2010's. You were a web master, a web developer, a web designer or something of the sort. But as soon as that complexity did hit, "front end engineering" became a specialization. Where it is really a cottage industry build on top of those complex browser engines, API's and sprawling specifications. For better or worse.
> However, the vast majority of sites are totally fine as static pages, as long as the user has a fast connection that makes loading between pages imperceptible.
Exactly. And that's still a completely valid use case.
The problem is how the industry has shoehorned an entire generation of front-end developers into believing that you need all those gizmo's to write HTML, CSS and JS.
When you're a budding front-end engineer and you land your first job from your internship, you're not even going to question the tools used by your employer. You're just going to use them because all you see is a big black box of complexity and nobody explains the history that has created that box.
I think that's why people will, like the author, ultimately drop out. When writing code for a living turns into this obligatory, rote exercise of juggling this mass of dependencies and complexity, with little to no time or authority to question why they need all this in the first place.
This is why I'm optimistic that some small companies or startups will look at this black box, go "nope" and look at simpler alternatives : maybe hotwire or htmx, or some other tech or architecture allows them to build the things they need to build quickly and efficiently and outpace their complexity-bound competition - much like Rails was the alternative back in 2004 to the J2EE behemoths of the day that the industry considered the "right" way to build a web app.
> it is staggering how easy it is to break many of those sites just by resizing the browser window.
I should say that a responsive website does not actually mean a website that responds to resizing the browser window - and that should not be taken to mean it's "broken". Saying that makes you sound like a typical sweatshop PM or stakeholder :) - i won't belabour the actual meaning here.
It does though, at least indirectly. If the point is to handle different screen sizes and resolutions properly that also has the side effect of handling window resizing; and if one doesn't work correctly the other will most likely have issues as well in some situations.
You can pick apart words and meanings as much as you want - a UI that stops fully functioning after the user makes a valid input I consider it broken. Hopefully you wouldn't call it "working as intended" either when a site becomes unscrollable, freezes up or literally moves sideways out of the browser's viewport when you type in a text field.
Resizing a window is not a weird edge case, it's been a basic UI feature for decades, supported even on some smartphones and tablets, and desktop applications have been able to handle it fine.
Intentionally broken is still broken.
Oh bullcrap.
This is just a rationalization from people who like the shiny.
What does that have to do with React and others? Tracking and ads are a regulation problem, pop-ups and auto-start videos are user-agent problems, and wait... loading screens? I don't understand, where do you see a loading screen in a normal web page? I mean in an SPA, sure but that's just bringing rendering to the client and people have been doing it since the invention of AJAX.
React and others didn't make the impossible possible, they just increase the development speed and make it much easier to manage complex state.
So, the post is against the complexity in development, you are against the complexity in the average website. I'm suggesting that the first one is neither the reason for the second, nor the enabler, and you can see that kind of user-hostility even in web-sites made with mootools, let alone jQuery or react.
There seems to be a confusion here.
In my day job, I write server-generated HTML for a growing and successful startup, without React, front-end frameworks or a particularly complicated front-end build setup (we do use AJAX, but in the "deliver server-rendered HTML and inject into the DOM" sense), and the user experience is comparable with many other web apps I use, some of which are almost certainly full-fledged SPAs, and is well-loved by our users. My team's productivity is easily double what I've experienced at jobs using the latest and greatest technologies.
Could I use this approach to build Google docs? Probably not, but then again, that's not what I'm building, and I don't need a tool capable of building that.
Injecting HTML into the DOM is literally what React does...
You can even server render that HTML and then hydrate the DOM with interactivity after the fact.
I don't understand why people make the distinction between server rendered and client rendered HTML when React can do both anyway.
The main value of React is being able to easily manage client state and efficient updating of the DOM.
If not a framework, how do you add interactivity to your pages? Vanilla JS?
The key part of that phrase is "server-rendered", not AJAX. Which yes, is possible with React as well, but it's incredibly rare to see a React app that utilizes actual browser navigation for the majority of it's interactions (posting forms, sessions via cookies, little to no JSON interaction).
There's certainly nothing stopping me from using React as a templating language, I don't but whatever, it's a fine choice. When I'm talking about "React apps", I guess I can be a bit more precise and say apps where control flow is dictated by the front end and the backend largely serves as an API (and maybe occasionally bootstraps a view).
> If not a framework, how do you add interactivity to your pages? Vanilla JS?
Mostly, yeah. We used a bit of Vue early on, but didn't see much benefit, there's still some code kicking around due to be transitioned. We'll use Stimulus when it makes sense, otherwise it's just vanilla JS and maybe helper libraries (checking our package.json, the only libraries we're using that aren't for CSS or third-party things like stripe are stimulus, codemirror, debounce, trix, and vue).
Flow control is definitely different between React apps and standard server rendered websites, but you are still effectively implementing the same thing in both cases.
I guess I'm not understanding how your team's productivity is "easily double" when to me, it sounds like you're describing run of the mill stuff that could easily be done in React or a backend framework.
In terms of increased productivity, things I've noticed that have helped with productivity:
- Using native browser functionality for navigation and form submission allows the browser itself to take on some of the work that would otherwise be filled in by custom code like maintaining browser history.
- A standard SPA requires that you maintain an API for the front end to talk to, which a server rendered framework has no need for (we do have an API, but it's specifically for customer usage and doesn't need to cover all use cases we need for our application)
- The backend is a 100% known environment, and while you always have to think about browser / device capability, this is greatly reduced when you have small amounts of Javascript, particularly when it's not essential for your page to function - there's also far lower demands on client machines since the bulk of the work is performed by the server.
Changes can often be applied in a single "layer". If I need to add a new field to a view, I can just add it to a template, whereas in an SPA I'd need to modify my React components as well as my API, potentially needing to care about API versioning, etc.
- More of a broader thing, but I find that environments that use front-end frameworks heavily tend to become more specialized quicker, and environments where you have specialization between front-end and back-end leads to increased needs for coordination for any non-trivial work, which ends up being a pretty big tax on velocity compared to having full-stack developers who can work on anything.
Too often interactivity can seem forced where the primary use is consumption of information, like hn.
The lack of distractions in the ui allows folks to focus on the conversation to some extent in a way that might be different.
Oh my, for example I never asked for smooth scrolling (I've actually disabled it in browser), instead someone insists on it and forces that on me with some javascript. Thanks, but no thanks.
I can't even have my own scrollbars from system theme most of the time (why even this?!).
What we have now is ultra slow interaction because of tons of JS. Constant cpu usage and battery drain. And most importantly boundless memory hogs such as oh so great interacting facebook that easily eats 2.5gigs of memory.
And don't get me started about "effects", animations, fades, stolen keyboard shortcuts, right clicks and every other bit that throws accessibility out of the window.
There are certainly poor front-end led sites but I think that can go away quickly after some experience in the field. Design is largely shielded from that if they stay in the land of Sketch or Figma instead of interacting with the real web.
This problem is as old as time: even in print, it takes experience and planning to visualize a digital composite as a physical object that lives up to your expectations.
Agree with everything you're saying, except for this.
I do user research as a job, which means that it is my day job to methodically interview and observe people using everything from web sites to apps to enterprise software. So far, I've had the privilege of doing so with more than 100 users.
What users expect is things that work quickly and reliably to get their job done, and then get out of the way. It doesn't matter whether they're booking a flight, buying cell phones or working in a complex workflow system.
Nobody, on the other hand, really wants bloated pictures, autoplaying videos, and dozens of different features without practical use - except for marketing people and managers.
Do they, though? Or is it the product managers who insist on such things? I'd put more weight on them. Some of it might be backed by user data, but generally it feels like they're pushing things unjustifiably or for wrong reasons.
Nope
Im going all on anecdote. Consider my SO is a youtuber and spends her days doing research for her videos, as do her friends on Tiktok and Insta. Not once has she ever mentioned any expectations despite my asking. She didnt even care about the cool "web app experience" from YT. I don't even think she cares about what I do.
Just because we over-engineer things to justify our absurd but nice salaries in the name of maintainability and More speed - more power does not make the mountain of dung smell any better.
Have they? I don't see that in my user stories
IMO, what matters most is coding efficiency, how fast can business problems be solved with a low enough error threshold.
I think you nailed it.
> Unless you're really invested in the product, it becomes hard to maintain enthusiasm.
+100 for that one. I spent a lot of time working on some absolutely bleeding edge crazy tech for a shitty client who made some stupid luxury product for rich people. Now I'm working on some 10 year old crufty web app for a non-profit that produces something of genuine public benefit and I'm more satisfied with my work than I have been in a long, long time.
I'm pretty sure that this is not true. You can ship great webapps without any of that overcomplicated nonsense. We're using one such right now.
These features could be feasibly implemented using jQuery or plain JavaScript but the more niceties like that you add, the more you can make the argument for UI frameworks.
I expect most experienced reddit users still use the old ui toggle. I expect new reddit users don't know it exists but would probably prefer it once they got over the 'change is bad hump'.
The fact that years later the old ui toggle is still present is a testament to how much the new richer ui failed for their power users.
old.reddit.com is another good example. Not everything needs to be an SPA.
Old reddit is a much more reasonable suggestion. It is fairly feature rich and is used by a large group of users. It seems to deliver ~340KB of Javascript. It's pretty nicely minified so I can't tell what its all related to but at least some of it must be related to the interactivity that HN is missing.
Like I said in my previous comment, you can do as old Reddit did and build up Javascript to solve these problems but at some stage it might make sense to jump to an SPA. Reddit made that decision. I think many would argue that they prefer old Reddit which is fair enough.
I think its hard to say if the Reddit team made the decision based on a legitimate and provable technical need and their old solution just wasn't cutting it or if they went the SPA route because "its what everyone else does" and "its easier to hire React devs".
OR - the means by which we produce systems is vastly more complicated than it needs to be.
In other words: HTML is designed for nice, light pages, but it's otherwise a steaming hot mess upon which to build single-page apps etc..
We are building the future on a few layers of archaic tools and the result is massively leaky abstraction.
So yes - our toolsets will inevitably expand to make all sorts of useless complexity - that will always be the case.
But for doing basic/cores stuff, it should be possible to avoid the trap.
Users absolutely don't give a shit about you using Grunt, Gulp, Burb, Babel, and the billions of other tools. They just want to pay the meal they ordered online.
Most sites and apps want users to click and engage as much as possible, not necessarily the most efficiently.
I'm not familiar with the Facebook website but I can't imagine that it needs any particularly complex application logic under the hood.
Pretty much anything is possible given enough time, but spending time building a complex application in vanilla JS, HTML and CSS doesn't seem like the most productive use of time when you can leverage a framework.
The build pipeline complaint also strikes me as hollow. Create React App outputs folder you can drag and drop onto a server and serve, same for Angular and I would assume Vue. Yes, it is a lot of JS from a ton of NPM libraries, but that's the trade-off when you get an entire ecosystem of code for free. If your application is security critical then consider either writing your own libraries or hosting security vetted copies of the libraries.
The real reason to leave this industry is that it's all the same work at the end of the day. Despite what application you build, whether it's a social network, a security application or collaborative tool like Figma or Trello, it all runs together as a mish-mash of views, data and DOM elements. Unless you're really invested in the product, it becomes hard to maintain enthusiasm. You can only roll a CSS library, or auth scheme or API library so many times before you're ready to start some new adventures in coding.