Hacker News Reader

I feel like there's a deep-rooted tension and aggression in the web space that is caused by the evolution of the web to an application platform.

I think we are increasingly needing a stronger separation between functionality oriented applications that operate in the browser vs media-based content (documents/videos/images/articles).

The web has become an unnecessary-hostile platform for web applications because you are standing on a thin layer of glass the whole time because you have to juggle so many combinations of environments and browsers and capabilities and devices and screen sizes and internet speeds and everything in between.

For example there's an insane amount of baggage involved today in deploying a decent production web application in terms of bundling the assets caching vendor prefixing feature detection and so on..

So much of that could go away if we had a more application-focused platform on the web.

So someone could say you want a web-based customer service desk application? Here install this 30MB bundle once and let us focus on everything else. It's not a big ask.

Instead we have a mindfuck of "minifying" "vendor prefixing" "css autopefix" "css sprite" "code splitting" "tree shaking" "___ javascript library that is only 4 kilo bytes!" "hash based cache busting strategy" "feature detection" and so on.

It just adds unnecessary complexity and baggage.

As a long-time web dev I'd like to see the web platform for applications evolve into a more friendly and predictable environment for the developers more similar to the mobile app platform.

"Here install this 30MB bundle once and let us focus on everything else. It's not a big ask."

That was basically Java applets, and then later JNLP and Flash.

It turns out it is a big ask. Users really don't want to install software, and their attention span is literally about two seconds. Javascript + DOM "won" over Java applets for two main reasons: you could access the whole browser window, and you could display something on the screen immediately without needing to load your whole application's functionality.

We didn't like JS back in 2002 either - the Java ecosystem was much more mature and easier to program with. But we put up with it because users expressed a very clear preference for DHTML apps over Java applets, and money follows users, and devs follow the money.

All the tree-shaking, code-splitting, minifying, etc. is there to preserve this "loads quickly" property as JS apps have gotten more complex. A lot of sites do it poorly, but think of those sites as prey for an enterprising startup willing to put the extra effort into snappiness.

I get it. My general point is that there's an imbalance between the method of application delivery and the importance of the application (or the frequency of use).

The method that we have makes sense for frequent hopping between different documents on different sites and spending some minutes on each. As was the case with the original "web of linked documents".

But now there's undue baggage and pressure and complexity imposed on application developers because on one hand they are developing sophisticated applications that people use daily for many hours.

On the other hand they have to worry about the most trivial things like if some library of bundle file is 200KB or 1MB.

Or worry if javascript is even enabled or not, if whatever CSS feature like flexbox or grids or whatever is supported or not.

A trivial thing turns into something complicated because you need fallbacks and polyfills and fallback for your fallback and you know the rest. It hurts the developers but also the users because time and effort that could be spent on the product is spent on this kind of stuff.

That's why I think the separation of content and application is becoming more important.

If you want snappy media that is not bloated and responsive and readable and open and all that fine.

But if you want a full-blown CRM or spreadsheet or customer support desk software and the like that you spend your day on let's give the developers a break and give them a predictable environment with a robust method of application delivery, without bean counting the bytes, and empower them to focus on the real problem that they are trying to solve for you.

Except it's not a big ask is it? Users routinely download 10-100meg apps on their phones and tablets and update them constantly.

Should desktop/laptops be the same? Is it only because desktops/laptops started long before the internet was fast enough to support that apps that they don't run like phones/tablets?

I don't want a locked down desktop/laptop. I'm only pointing that that more people than own desktop/laptops are constantly downloading and installing 30M bundles

A big problem in the mobile app ecosystem is that users don't routinely download 10-100meg apps. Most users have 6-12 apps they've already downloaded and use routinely and then say "Eh, no thanks" to more. This is why it's so hard to break into the App Store as an indie developer.

I can think of at least two instances in the last week where I've had a desire for the functionality offered by a big-name product (Groupon and Zillow), went to their mobile website, was confronted with a nearly-nonfunctional mess and a prompt to download their app, and then said, "Eh, I don't care enough to bother and wait for it to download."

The discussion on this thread is confirming the top poster's point, that much of what web developers do is user hostile. People here are aguing that ordinary users don't want to promiscuously use lots of apps downloaded off the internet. Then they call this mindset a "problem" and argue that therefore we need JavaScript to trick them into doing it without noticing.

In so far as your web app really is something that should be a full scale app (google maps being the classic example) this is a great trick. But as an industry, we have incentive to shove complex apps down people's throats when the use case requires plain-old-media with just a bit of dynamic stuff for navigation and forms.

Also because when you have an 8GB phone, there are only so many 50-500mb apps you can install, given the space already taken up by personal files and compulsory Android apps.

I prefer web apps because when I go to a bar and want to order from my table, or want to see the schedule for a conference I'm attending, I don't want to go to the trouble of installing a new app for something I'm only going to use once. This used to be a lot worse when apps asked for a load of permissions upfront which it wouldn't be sensible to grant, but these apps still often take up around 100mb in storage, which can mean having to find something to uninstall if you have limited space.

> Users routinely download 10-100meg apps on their phones and tablets and update them constantly.

That's a pretty horrid mischaracterization. Users may download and install apps that are tens of megabytes per bundle, but at least the downloaded blob is then entirely local. The apps don't redownload themselves on every startup.

Let's compare that to a bloated megalith webpage with framework machinery, a dozen trackers and $deity knows what else. "ETag has changed, please wait while we drip feed you this >20MB JS+CSS gob. Oh, and btw - you can't see the page text at all until the download has been processed."

Yuck.

> So much of that could go away if we had a more application-focused platform on the web.

We already have that platform, the desktop. Sure the distribution side of things could be improved, but there is nothing wrong with the platform.

There is one issue with desktop applications: user has to _trust_ the developer of application he's going to install. Because an application get access to everything in the user directory. I'm under impression this is the major reason for web apps becoming popular on desktop: most of the time, running software in browser is totally safe for user, unlike running native applications.

The article deals with text readability and typography, not with an over reliance on JavaScript front-end frameworks to render « simple » text.

I think geebee's point is that the two trends go together chronologically; is there a causal relationship, or is it a spurious correlation?

That's absolutely true. However, my question is whether part of the decline of text readability is due to a resume building need to involve technologies that don't have much to do with basic text.

Here's the thing - people don't like to bring in a more complex technology simply to do exactly the same thing as they could do with a simpler one. They need to justify its presence in there somehow.

For instance, supposed you decided to re-implement hacker news with a client heavy javascript framework. Would you leave it looking exactly the same as before? Almost certainly not, you'd start using that javascript stuff, and (in my opinion), the end result would no longer be the simple, easy to read, text based website that it currently is.

That's the connection I'm getting at here (and once again, it's something I'm mulling over, not a hard conclusion I've reached).

I would agree that what you state are factors, but I would disagree that they are the main factors.

One thing I notice in my work (in product management) is that people naturally gravitate towards shiny things. So we design things to be shiny in order to attract those people.

At various points, a specific aesthetic gains popularity because, for well-founded reasons, it increases usability and readability. Then everyone starts to imitate it, partly because it works, but also partly because people are drawn to it. Then frameworks are created to enable teams to rapidly replicate the style.

At a certain point, the frameworks are good enough to just replicate the style in basic settings with little input needed from someone who is actually thinking really hard about the design. In many ways that's a good thing because it lowers the barrier to entry. It's much easier to make things because the framework drastically reduces the amount of wheel reinventing you'd need to do. But you end up with designs where nobody really thought that hard about it - and so you end up proliferating potentially bad defaults encoded in the frameworks.

I'm personally much more willing to believe that the decline in overall design quality is due to negligence from convenience.

In my work, I have noticed that users are reluctant to move towards shiny things, and it is the developers of the shiny things and some manegers who gravitate. The rest of us get pushed.

Exactly, in web design almost no one actually thinks about the user, it's all about impressing each other with shiny things, rather than well thought out user experience.

I think you're conflating design and engineering.

It's rarely the case that you change design because you selected a new technology; rather you usually select a new technology to enable changes in design.

If I switched from React to Vue for a Hacker News viewer I'm not also going to change the design of the project just because. But if I wanted a dashboard to become dynamic and allow for smoother user experiences without a full page refresh each time chances are I'm going to introduce JavaScript to a page that was previously just HTML and CSS.

Nah, the core problem on is the misuse of opacity, too many shades of one color (such as the light gray in the article) instead of relying on weight variation, dividers, italics, etc.

Take this block of text in the article:

"I thought my eyesight was beginning to go. It turns out, I’m suffering from design."

Instead of leaving it a legible black and have the divider + italics convey the separation from the article...

They went with rgba(0,0,0,0.5) on a font that is hard to read on a white background with that shade of a gray. Try removing those sort of CSS rules from the Wired Article and you'll find it much more legible.

They repeat this sin whenever they quote someone such as:

A color is a color isn’t a color… …not to computers…and not to the human eye.

They also put a ton of whitespace around the quote which is already enough to separate it. The absurdly annoying light gray is annoying and not required.

Content producers shouldn't need more than a static site generator and a theme backed by a good custom frontend for inserting new content

The web as a publishing platform shouldn't need React or 2MB of js libraries

Web apps are a different story but have also different requirements

I've been mostly a web developer for the past 20 years and I can't understand why there isn't a good solution yet

Look at 4chan or Craigslist

They're highly successful and they serve pure static (ugly) html

There are also many sites that are highly successful and use 2MB of javascript. I'm not sure what this proves, except that when an app is useful users won't be put off by the technology or even user experience.

Ok, many developers, especially at the beginning of their careers, do like to introduce new things into the projects when they believe those things could advance their careers or even simply sound cool to talk to the peers about. But this is not the reason for the unreadable web.

I think the reason is simpler, more like fashion: most people who are in a position to play with fonts and colors have absolutely no idea what they are doing and make decisions by copying somebody else who they perceive as cool, and there is always pressure to make it look cool, so it spreads.

Although this isn't directly related to the article, I can't upvote this enough.

To be clear, the article is almost solely about contrast between text and background colors, not JS heavy frontends. But I think what you've stated is very true and is also my opinion about the current state of web frontend.

Like another user said here, the contrast is a result of designers working with a page with too much content, and trying to reduce the feeling of content overwhelm. I don't think heavy JS frontend is directly related to that. But what you've said should not be discounted.