Hacker News Reader

Comment by gorpomon | Hacker News Reader

It's disheartening to explain this over and over again, but these frameworks are a-ok because user's expectations for the web have grown astronomically. The complicated web is here because users insist on interaction, and if any web page has more than around 10 interactions on it, the resultant complexity is best handled by a framework. I recently got to do a jQuery job for a client-- it wasn't a pleasant blast from the past but a kludgey swamp to slog through.

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.

View on HN

User expectations or client expectations?

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.

IMO, phone apps changed users’ expectations for websites. They want the same interactivity on Facebook.com that they get on the Facebook app. Same with Kayak (or whatever travel site people use these days). Same with Google Maps. 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.

Well, this goes even deeper.

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.

> 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.

I think it's more likely that faster CPUs will make CPU hog pages less noticeable. Companies keep making bloated pages but users will decreasingly care.

It's not about the cost of the end-user bloat (although that's a problem), but the cost of development and maintenance required by complex front-end frameworks and architectures.

But that does not mean expectations of web users have to be thrown under the bus. Such as, you click on something by mistake and try to fix it by using Back button. With facebook nope, if you forgot to open the link in a new tab, the original view is irretrievably lost. You sometimes can't even scroll back to review something, whole page gets reloaded and it vanishes.

Supposedly one-page apps are meant to improve latency and interactivity, but FB is slow as molasses and frustrating regardless.

FB's terrible back functionality is their own fault since libraries like React Router give you a ton of control over back/forward behavior.

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.

> 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.

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.

To be honest, I see those even less in modern SPAs. Usual suspects are sites which load every possible js lib in the universe until some integration works and they can display all the ads.

There seems to be a confusion here.

>So far I haven't met a user who asked for ads

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.

I would say both. User in the sense that people expect the web to behave and be just as rich and fluid as a native app (and will often leave or mistrust you otherwise) and Client in the sense that having a rich web experience drives revenue and whatever other business metrics.

> 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.

> and will often leave or mistrust you otherwise

Oh bullcrap.

This is just a rationalization from people who like the shiny.

> I should say that a responsive website does not actually mean a website that responds to resizing the browser window

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.

No what you are talking about is called fluid design not responsive. So whether a website responds fluidly to browser resizing is a design decision and not indicative of something being broken. This is such a common and frustrating misconception.

Sure, you can call not supporting one of the most basic UI features a "design decision", but it's a terrible decision and it won't protect you against valid complaints from users, just like apps like Skype got complaints for mishandling the window's close button.

Intentionally broken is still broken.

This is a common response to complaints about front end complexity, but how true is it, or how true does it have to be? We're posting on a very successful website that could have easily been built in the early 2000s in terms of technology, if not earlier.

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.

There's no shortage of hn clients with increased interaction and none have seemed to be used more than the site itself.

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.

> we do use AJAX, but in the "deliver server-rendered HTML and inject into the DOM" sense

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?

> Injecting HTML into the DOM is literally what React does...

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).

I don't really see a big difference between POSTing with a form vs a request or between sessions and tokens.

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.

Oh, we're absolutely using a backend framework, I didn't mean to imply that we're building everything with raw CGI scripts or something like that.

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.

In my not humble at all opinion - user expectations sank to absolute lowest minimum.

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.

A lot of these gripes seem to be aimed at either poor imitations of well designed and implemented marketing pages or just straight up poor designs. From my experience as a front ender, I want to make the user experience as welcoming as possible instead of replacing native scrolling, stolen keyboard shortcuts, etc. It’s a designer that tries to impose their mock-up on browser defaults and only with front end pushback do we get a mediocre middle ground.

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.

> user's expectations for the web have grown astronomically.

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.

> The complicated web is here because users insist on interaction

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.

> user's expectations for the web have grown astronomically. The complicated web is here because users insist on interaction,

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.

>user's expectations for the web have grown astronomically

Have they? I don't see that in my user stories

Users just want it to work. I think the problem is too many developers trying to impress each other for status.

IMO, what matters most is coding efficiency, how fast can business problems be solved with a low enough error threshold.

It's a combination of whimsical requirements from PMs and designers, plus FOMO and resume-driven development among developers. None of which have anything to do with actual end-user needs.

There's also a Large Corp dynamic, where to maintain consistent user experience across the product portfolio, a common UI platform is built. The platform is then mainly driven by the requirements of the most dynamically interactive applications, leading to a complexity creep - even though most of the products could be simple CRUD web pages.

"resume-driven development"

I think you nailed it.

Companies overhire devs after raising money so it looks like they're doing a lot of interesting stuff. PMs and managers need to find stuff for these devs to do, hence they come up with overcomplicating their existing tech, redesigns, etc.

And on top of that, most users want it to work the same it worked yesterday. Nothing drives me up the wall more than neverending stream of updates for anything and everything, be it PC, mobile, web, even cars. I understand it's great for job security and/or resume-filling, I just wish those developers would consider the difficulty of,for example, trying to explain to 60 years old nurse why the thing that worked yesterday doesn't work anymore or why it suddenly behaves differently.

Having been around since the pre-CSS days up to the time of attempting to hack my own build pipeline with the YUI compressor, using npm is like a dream. The first batch of tools like grunt were very rough around the edges and hard to use, but the pace of improvements has been extremely impressive.

> 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.

> It's disheartening to explain this over and over again, but these frameworks are a-ok because user's expectations for the web have grown astronomically.

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.

Hacker News is purposely utilitarian and that's fine but I don't think general audiences would tolerate it. You have to manually check if someone responded to your comment. I don't think its too unreasonable to say that most users expect a notifications system on a platform like this. Editing a comment takes you to a separate screen and leaves you there once you're done, you have to manually navigate back to the discussion you were on. Reddit lets you edit your comment in place and continue from where you left off straight away.

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.

It seems to me you're confusing HN's lack of some common forum features with the way that those features would be implemented; I would imagine that if HN did get, say, notifications, they would largely work without javascript, or some big complicated frontend build process.

old.reddit.com is another good example. Not everything needs to be an SPA.

The parent suggested HN as an example of an application that didn't need a lot of client code. I think its still fair to say that it doesn't have many of the features that ordinary users have come to expect.

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".

old.reddit.com works without javascript, notifications and all.

I tried there and upvotes, replying to comments and editing comments don't work. I can't speak to notifications but I'll accept that they work.

When reddit switched to their new 'featureful and rich' ui they provided a way to access the old user interface which is much more utilitarian and flat.

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.

This is the story you want to believe in. I was doing the exact same kind of interactive apps 10 years ago without any of this crap. Some things are easier, but their are not worth the 10x complexity.

" The complicated web is here because users insist on interaction, "

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.

You're not wrong, I think most in this thread won't debate that user expectations are ever increasing. I think the issue is that the complexity doesn't scale with the perceived benefits and it feels totally out of whack right now. There's also a lot of cargo-culting going on with massively complicated tools like Gatsby being deployed to build blogs and static marketing pages.

> It's disheartening to explain this over and over again, but these frameworks are a-ok because user's expectations for the web have grown astronomically.

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.

As a user I much prefer old style sites like HN, Wikipedia and the old Reddit to the javascripted up ones for most stuff. And I've got a readability extension to turn monstrosities like bloomberg.com into something like a relaxing page of text.

Yeah agreed on all counts. React apps are a real joy to create. The UI just works like magic with reactive updates. Modern js tooling gives me a fun and effortless way to produce user interfaces.

I agree, but I'd add that what really gets bland is just how uninteresting the outcome of all the complexity is in most things. For example, a NextJs app normalized into a hundred components, using redux, styles in js, webpack probably, npm scripts, jest, etc.. with the ultimate output being a probably barely responsive mediocre looking standard webpage with a navigation that doesn't work on a device you didn't anticipate because you re-invented links

Efficient interactions might not be the same as effective interactions.

Most sites and apps want users to click and engage as much as possible, not necessarily the most efficiently.

This. Every tool that the author complains about serves a purpose and are optional. Using frameworks can help avoid the complexity of configuration too. https://asd.learnlearn.in/use-a-framework/

My place is implementing stuff in React, not for any reason, just because. I have suggesting that server side rendering might make things simpler, but it just assumed that we need React in this day an age.

complex UIs don't require complex frameworks

What _do_ they require?

They require identifying all the interaction paths that a user can take through the application so that any function associated with an interaction can correctly update the state of the application's data model. Vanilla JS, HTML, and CSS.

Do you think that's feasible for a website like Facebook? It seems like it would be much more difficult than using a framework.

Why would it not be possible? What cant you do with js that other fancy frameworks can?

I didn't say not possible, I said feasible.

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.

Developers that have experience creating native applications are used to writing code that manages the application state and it's relation to UI interactions and data updates. In native-land, the UI frameworks are primarily the UI widgets and all of the application logic is written by the application developers in their chosen language. The corollary to this for web development is that HTML and maybe a few specialized graphics libraries like D3.js provide the UI thingies and the application logic (event handling, data fetching, etc.) is written in Javascript.

I'm not familiar with the Facebook website but I can't imagine that it needs any particularly complex application logic under the hood.

Agree!

Reply on news.ycombinator.com