There's always been poorly-written software, poorly-created websites, bad UIs, bad UX, etc. And I don't see that changing anytime soon. Suggesting that the entire web is devolving into a vat of poor decisions is, I think, a bit alarmist. Technology changes, things progress, sometimes things get slightly worse before they get better. But I think, on the whole, things are moving in a good direction. And we'll always be able to pick out a few bad examples to justify why the sky is falling. But in the end, I much prefer the current state of affairs to the way things were a decade ago.

It's what the developers say. Every developer has latest macbook, works on a shiny new office with AC with all the bandwidth and gadgets. And they think people all around the world also has the same thing.

Whereas lots of users don't care about the AJAX loading. Users want websites to be fast and less annoying. But, developers only care about latest hot frameworks even though that will make things slow for users.

Newest Youtube redesign is the same. It consumes more cpu and way much slower than the previous one. I know because I don't have a high end laptop and 100mbps internet. It does not matter because Google employees use all the latest gadgets.

Well, pulling some JSON via AJAX and updating a small part of the page is faster than reloading the entire thing.

And yet websites are slow. That's not just "get off my lawn" crankiness, either. We're now downloading multiple megabytes, and things are rendered via javascript late in the process, so we start seeing content later than we used to, and we get the final render later than we used to.

Modern websites are largely slow and annoying, a topic that has come up many, many times--with benchmarks--on HN.

I think the biggest culprit over the web, the thing that makes me hesitant as a mobile user to visit websites willy nilly, is media content, such as images, sound, and video. Many websites look empty without media, so people splatter at least a few things on there, as do advertisements, and I think that's easily a few MB.

I also think the biggest resource that people are consuming nowadays, including well-to-do people with iPhones, is not CPU, RAM, or even battery resource, but mobile data limits.

But HTML CSS JS cannot compete against rich media, and how badly it drains the user's most finite resource of all -- mobile data. That's what makes an information lookup even on native Yelp costly to the user.

1 request pulling down 1 Mb can be quicker than 4 requests for 10Kb each.

[0]: http://idlewords.com/talks/website_obesity.htm

https://youtube.googleblog.com/2017/05/a-sneak-peek-at-youtu...

https://github.com/youtube/spfjs

https://www.youtube.com/watch?v=yNe_HdayTtY

fyi: It's generally considered bad practice to assume bad intentions when alternative explanations suffice.

With the framing of pushing browsers to implementing the Web Components standard it seems much less evil.

I think the true motivations are likely somewhere in the middle.

This has nothing to do with "back in the old days". The web in the 90s was very often horrible, and Flash made it worse (although it's a pity Google and Apple killed it - Adobe could well have opened it when they had a chance and we could all enjoy an independent open platform - but that's a topic for another discussion.)

I took a screenshot, cropped it, saved it as PNG, and embedded it with a plain old image tag. 3KB vs. 3000KB, and maybe I lost some fancy auto-scaling magic the culled JavaScript did. Big deal.

This is a company that positions itself as the new way for creative people to make a living in the 21st century, and they need multiple megabytes and several seconds to load the 175x36 road into that future. We're not quite in the future yet, and 3MB is still a lot to ask of limited data plans.

They're probably hooking into their analytics platform.

Yes, but the bad websites in the old days didn't lug in a bunch of unnecessary js to accomplish their aim. I do think things are improving as a whole, like you do, but we're currently on the latter half of a pendulum swing from barebones to over-engineered.

And "Flash sucked" is no excuse for the web being bloated and delivering text content in ridiculously stupid ways today.

Imagine this. You know you can script JS in photoshop. So someone comes with the "brilliant" idea and solution of making apps by scripting PSDs. Suddenly all the rage comes and every dude out there boasts his new psd-app development skills on their resumes. And everyone forgets that the JS right there in Photoshop is for PSD scripting, not for making apps. Same here - CSS is for styling HTML documents. JS is for making documents a bit more interactive (think, "click that button to view some visualization"). The web environment was not made for apps and it shouldnt have apps developed on it.

I kind of disagree. The web is no longer about a single consistent form of content. You have sites. And you have web apps. They are not the same thing. When people ask me what I do for a living, I say, "I write web apps." They often say, "oh, cool, I've been looking for a web designer." I say, "no, I don't really do web design for web sites, I build software applications that run on a web page." So maybe the world isn't entirely used to the concept yet, but that doesn't mean there isn't a valid separation. A web app should not be like an informational web site, and vice versa. But that doesn't mean one should disappear. That's up to designers to understand, not really for users to understand.

I feel like the web is a really poor paradigm for many apps. Especially business apps where users can be trained to use a more complex but more efficient interface. The web drives us all to create "universal" style applications that anyone can use more or less without training. Which is grand for the public but I think really backwards inside organisations.

There is definitely a danger of "dumbing down" our software too much, but for most purposes I think it is orthogonal to the technology used. I suspect mobile apps have done far more to dumb down software than the evolution of the web in recent years, for example.

Part of the problem is that good tools to develop more powerful, flexible software haven't been available on some of these platforms. For example, JavaScript only discovered modular design relatively recently, and even today its community is still fighting early battles like how to manage dependencies and how to build larger projects efficiently. The tools are decades behind the curve compared to how we make desktop, server and embedded software.

Another part of the problem is that a lot of the people developing web and mobile apps are relatively unskilled and inexperienced, either having never worked outside that part of the software industry or having moved into it from a less technical role like graphic design or marketing. They don't even realise how far behind the curve their tools are, because they wouldn't recognise or know how to use more powerful tools if they had them.

There's also the non-problem that for many purposes, dumbed down software does the job just fine. A great deal of useful, real world work does not require massive business software suites, bought for staggering sums of money from big name suppliers. If there's one thing we've learned from the software success stories of recent years, it's that very often the information you're working with is relatively simple, and the abilities to organise it and to communicate about it with the right people in a convenient way are worth a lot. There's nothing wrong with providing those abilities to new users in a simple way that does not require extensive training; in fact, it's highly desirable to do so.

1. Make something as intuitive and easy to use as possible for someone seeing it for the first time

2. Make something as efficient as possible for someone who knows how to use it

Now, common sense says that #1 is more important when it's a mass consumer app that many users will spend little time on. And it also says that #2 is more important when it's an app that does "work" that users will actually spend countless hours working in.

The problem is that #1 is often pushed too hard by managers, salespeople and designers (especially designers with mainly web or mobile experience) even when your use case requires #2. This is because they want to make a good first impression when they show the app to potential customers, especially when the app is new and without an established user base. "Look how I can do this in 3 clicks, the app guides you through it!" And it is often because they simply don't know better and they're just parroting what they're used to.

It is not an inherent problem with the platform. As an example, MS has Office on the web and they didn't create a dumbed down UI for it.

Also, HTTP 2.0 fell victim to too much pressure for backwards compatibility.

Things aren't improving.

Website owners/designers/what have you must figure out which of the audiences to appeal to, if not both at once.

I respectfully disagree. There's a spectrum here, and there's no reason you shouldn't have a site that has some relatively static parts that are purely about providing information and other more interactive parts that work more like an app, if that is what the purpose of the site calls for.

Also vendor lock-in and a mobile/tablet-only mindset. Fine for some apps, not so great for applications that should be available to all (e.g. a national income tax filing application or a public transport travel planner).

A good responsive webapp works on every modern computing device out there. That really is awesome.

> The web environment was not made for apps and it shouldnt have apps developed on it.

It evolved into it. That doesn't mean that static no-nonsense informative websites should not exist; on the contrary. It means that despite its flaws, we have a modern application execution environment that is cross-platform and constantly updated (if we limit the discussion to Chrome, Edge, and Firefox for now which are kept up-to-date automatically on most operating systems). It's not perfect, but at least it's inclusive.

That's the other extreme, which is even worse. I'm happy the web has evolved from simple http/css web pages.

HTML is for content, not styling.

Even Hacker News feels a little bit too fancy with its threaded discussions and such, but it is by far one of the best sites today, in the Web 2.0 quagmire of needlessly active content and out-of-control styling.

This is about as fancy as I want a website to be: http://farm4.static.flickr.com/3194/2830673252_16c7bf336e_o.... https://d3ui957tjb5bqd.cloudfront.net/uploads/2016/07/popula...

(There is some JSP stuff, but most of that is still plain HTML with stuff dropped in strategically.)

I like being able to deliver all the useful information content in the initcwnd for the HTML, and have a page weight of generally << 100kB (ignoring ads).

http://m.earth.org.uk/

http://m.earth.org.uk/note-on-site-technicals.html

I honestly don't know if my pages suck for normal humans to use, maybe I should worry more about that...

When it's done wrong, yes it's a poor experience and is most likely done for doing it sake. With no thought to the UX experience or performance. Twitter using hash urls for the first time was one.

But if you design it from a UX and performance perspective it can work well. Especially if you allow it degrade gracefully.

For example Google maps, or Google docs etc. But also stuff like a search app like airbnb.com.

An app can have better performance then pure html pages as when you transition you can have it smoother, and only load the differences. It can improve interaction as the whole page isn't cleared and then refreshed.

Google is recommending going this way for web performance https://developers.google.com/web/fundamentals/performance/p...

I think in this thread we are only remembering web apps that have gone horribly bad, like reddit for example. But we don't remember it when it just works

Has not been my experience. I did an experiment once -- two weeks without any JS on my Firefox. Tried to open everything in there first.

I did not count totals for the 9 days I was able to endure but I did count medians and I can tell you that only 1 in 50-60 websites had any form of graceful degradation. And most of the time it wasn't graceful at all...

Sounds good in theory but it is definitely not happening in practice, is what I am saying. Businesses view it as too much expense.

Single Page Apps For the vast majority of content are such a horrible user experience, I have to believe the backlash will be swift and severe. They will be condemned to the bad ideas pile with table based layouts and Flash sites, with the latter, they share a lot of similarities.

But despite my confidence, I confess I've been mystified why they ever took off at all. They seem so clearly an impedance mismatch with the kind of static-ish content the web is really rather good at, I didn't expect them to take off the way they have. I understand fashion, and I understand when SPAs might be useful, but still. Why? (a genuine question).

And the trend only continues, with the wave of virtual DOM technologies that have taken what used to be a static-based layout engine and made it quite dynamic.

As for popularity, is there any other competing medium that allows an app to pretty much instantly run anywhere regardless of platform without user installation? No. And for that reason, they will always remain an intriguing way to distribute software.

Just as many of the first apps for iphoneOS ten years ago were silly and stupid, a lot of it boils down to taste. Not all web apps are worth it, but so many are! Tastes will evolve for both users and developers.

That's what I don't get about SPAs' popularity: they're just as bad as Flash sites, but at least with Flash everything was self-contained, and very, very few people tried to do everything in Flash (and those who did were roundly mocked for it).

But now it's 2017, and every time one comments 'why does Blogger require me to execute code in order to view text & images?' some kid will say, 'hey grandpa, get off the Internet so the rest of us can get work done!'

The mass adoption of HTML+CSS+JavaScript is, I'll grant, a massive leap forward in terms of pragmatism but a massive leap backward in terms of privacy, security, usability, performance and sanity.

2. Analytics.

3. Cool visual effects.

Companies wanted to know more about how their websites are used. A noble goal for sure but nowadays it's a blatant surveillance.

https://www.earth.org.uk/OpenTRV-demo.html

I generally think apps on phones are a poor deal for security and reliability, so there is scope for using browsers as a portable virtual machine for all but the most critical/local of services. I was thinking this this morning before I noticed the HN story!

So, I like my pages to be clean and small, and I'd like Web apps to be distinct and reliable, and in some cases work off-line to avoid the need for walled-garden native code.

You got it. I'm finishing up a contract for one such firm that loves to use Wordpress for everything when 9/10 of their sites could be better served by static HTML pages and better CSS. But no, that's soooooo last decade, so the users get a Wordpress/Sass can of worms that requires entire LAMP and Node.js stacks to operate properly.

I was thinking about rebuilding my portfolio site in a "responsive framework", but decided against it when I realized I can achieve the same effect with static HTML and separate CSS files for each page.

Back in 2005 when Mozilla released XUL, I thought we would have the best of both worlds: Standard internet connectivity (via http/s) with real application interfaces. Unfortunately the hacky Javascript/HTML duo won the race for some reason (granted, in the late 90s I liked Java Applets).

Even after many years of Windows dominating the desktop, installing an application on Microsoft's platform typically means finding an installer from a reputable source, waiting around while it runs, answering all kinds of questions you mostly don't care about but that will catch you out if you do forgot to check/uncheck something significant, fixing (or not) whatever incompatibilities it has with other software you might remember installing last year, hoping it doesn't crash your video driver or corrupt your files because your LAN connectivity dropped out for a few seconds or screw up your hard drive with its poorly implemented and malware-like copy protection technology, two days later getting your 57th non-standard prompt this week to update something using your 57th non-standard update mechanism this week because of $SCARY_SECURITY_WARNING, wondering whether the result of that will actually be the same as just installing the new version from their web site, wondering whether you can move your ludicrously expensive business software to your new PC when the current one's hard drive fails, never quite knowing where your important data is and whether your application follows proper Windows standards so you can at least back your data up, and then having endless problems because you once uninstalled an old version of something vaguely related that didn't clean up properly.

Here's the equivalent with a web app: Go to web site and use the software.

Here's the equivalent with a mobile app and app store: Tap app store icon. Search for software and tap install button. Use app.

If Microsoft had managed to address this most fundamental set of requirements somewhere in the first 15 or 20 years of Windows' life, I still believe it would be the dominant tech business today, instead of slowly sliding towards irrelevance as it uses up its war chest failing to take advantage of one new trend after another.

And Microsoft is wasting opportunities even today. Windows is still very widely used yet they fail to capitalize on this. What was their solution? Advertisements! They lost a lot of user capital, so to speak, due to this.

To this day, you have to install paid software like Sandboxie if you want a macOS / FreeBSD-style-jails environment where apps can't meddle with one another (or the OS itself).

"But but but... it's gonna break this office's 20 year-old setup!" -- this is a very overstated danger. Microsoft has been really good at backwards compatibility. Sooner or later though, some sacrifices have to be made. If your accounting software relies on the ability to write to your entire disk, maybe it has to go. (Furthermore, I've successfully migrated one office's "database" and shared sheets to a dedicated small NAS machine and simply remounted their network dirs again to point to the new location. Took 15 minutes for an office with 5 machines.)

Several weeks ago there was a small discussion here in HN about OS-es morphing into a bunch of services you can use in a highly efficient manner. Of course most people scratched it off as "might break too much legacy software". Well, sure it could. Shouldn't be a reason why we shouldn't start and experiment along the way. I am sure the dangers are overstated anyway. Everybody is like "nooooo, the sky is gonna fall!" and nobody is actually willing to try.

Thanks to the internet archive this time we can at least just link back to all the old posts about these topics instead of hashing it out again. Maybe it helps.

http://badassjs.com/post/43158184752/qt-gui-toolkit-ported-t...

Furthermore, the day a Facebook or a Blogspot will start drawing pixels instead of text people will keep using them and good by to copy and paste. We'll even get technical blogs with code samples which are impossible to copy, and some clever W3C standard to introduce copy and paste for text rendered into canvas.

https://blog.plan99.net/its-time-to-kill-the-web-974a9fe80c8... HN discussion: https://news.ycombinator.com/item?id=15321015

(I am NOT the author)

As a developer who can build both traditional multi-page websites and single page apps, I'd rather build single page apps from both a development productivity and UX perspective.

As a developer, when you get used to building web apps, it's just faster especially if you're a full stack developer.

Most seem to think that if you are not using Angular/React/etc, you are doing it wrong, you live in the past. But the large majority of our websites could easily be plain HTML + some Javascript to spice everything!

I'm still a very big fan of progressive enhancement and of sites that do work when javascript is disabled, even if they are then not as pretty.

No. Because if they did, they might not make the changes.

Much of this is likely driven by 'marketing' where there was/is a miss-belief that if the site is not using the newest whiz-bang tech it will see reduced "engagement".

But what the marketers can't fathom is that people come to the site for the sites content, not the sites technology stack.

If that's the case these marketers should quit and get jobs as developers, they'll get paid more.

Also it doesn't help that developers also tend to love doing new stuff, exploring and all.

Branding and communication go beyond reacting to numbers - it's getting a strategic vision and develop it in a way your customers relate to.

From what I've read I don't know what kind of marketing people you guys are in touch with... my god.

Well be careful with the marketers you hire - because you have a lot of developers who get bored and shift to marketing, and bring some bad habits with them.

Tech stack is not up to marketing to decide - what marketing may say is that the app/site performance is making you lose customers, or the design needs to be improved.

Get proper marketers.

Most web apps violate basic user interface design and don't even have working keyboard shortcuts. And let's not get started on user-definable menus, arbitrary undo, re-ordering of interface elements, scripting, and other advanced features.

Don't get me wrong, I don't want to sound negative and to each his own. I personally don't use a web app for mail and have found absolutely zero use for any other web application I've tried so far.

The desktop is a different world.

Web apps should be able to shine as portable consume-mainly low-pain deployments.

I am extremely saddened this comes up less and less.

An ancient accounting office where you can do EVERYTHING with F1-F12 and a bunch of other shortcuts, written in 1993, is more advanced in terms of UX compared to most web apps.

Much of the code running in these apps bypasses engineering and source control, it is injected into the page by services like https://segment.com/ and handled by Marketing, not Engineering. So you see cases where the app works great on dev machines and in prod loads 20x slower.

E.g. web-based bitmap editors, web-based IDEs, web-based audio editors, web-based file management, etc.

And for sure, I've stopped even learning web technologies, as they are more hassle than they're worth - just as much cognitive load as it takes to build a native app, with none of the benefits.

So, I build native apps. And if I need it to be cross-platform, I target SDL and OpenGL with a single GUI library that works the same, everywhere.

It means I never have to read a single line of CSS ever again, and .. I like that! A lot! Plus, all my apps run everywhere, and always look exactly the same - my users like that too!

These approaches all have their pluses/minuses too, of course, but I have found that by exercising platform chops, the workload is minimal once the homework is done.

I find it utterly pleasant to code something up in Lua, ship the bins to the devices directly, and see the same thing on every machine. Even between libui and MOAI projects there are chances to share data - i.e. use a lab tool written in libUI to generate content consumed by the game engine...

Its like the web, only completely the opposite: you're not targeting someone else app (the web client), but rather running your own client (app).

MOAI DEV: https://github.com/moai/moai-dev

Warning: some effort is required, but .. once you get the hosts running on all platform targets (Win/MacOS/Linux/iOS/Android/&etc.), the true value shines and cross-platform nirvana can be attained. Bonus points for having Hanappe/Flower and/or whatever else involved as a 'higher layer' UI management abstraction on top of the GL pipeline ..

For users, now even for me, if I go to a web site to do something that seems simple and they say "do you want to download our app?" I feel my tempature rise a bit. No, I don't want to give you a foothold on my phone/computer I just want to do this simple thing this instant while downloading nothing.

The developer case is worse: platform GUI development goes from complicated to horrendous. And if you've done it for one you've done it for none of the other platforms. What was needed here was for everyone to understand MVP (model-view-presenter), implement most of their logic in model and presenter layers and then only have the V as a thin, platform-specific bit that presented the content to the user. Instead we either got Swing (a run-everywhere library that looked exactly the same everywhere and fit in nowhere) or these lowest-common-demonitor "native" frameworks which looked ok but often missed key functionality on various platforms. So they were either really ugly or really complex. And this was, IMO, a result of poor design processes: the GUI's were written such that business logic was hopelessly engangled with GUI/View code.

So the web basically gave us a kind of Swing where it did fit in. So the web became a favorite GUI framework. But it wasn't designed to be a GUI framework so it was terrible at it [1]. But still, it was perceived to be easier than native (and indeed, it had advantages: much harder to embed business logic in your view because the view is written in a completely different, non-turing-compliant language) so people were happy to use it. Including doing insane things like trying to run OpenGL in the browser so they could have 3D games there (making the browser nothing more than an app delivery mechanism) or even people asking for an OS that is just a browser.

I don't know how things will turn out, but at least if WebAssembly gets popular maybe I'll at least be spared dealing with the insult to engineering known as JavaScript.

[1] Some people don't get this. In this very thread there is someone asking why there are no "native" components like date pickers and so on...

There is nothing wrong with hype. The big problem is anything new avoids proper scrutiny by forcefully marketing what it seeks to replace as 'obsolete' and criticism as anti-change. If its by a big player people latch on hoping to consult or acquire employable skills and the din by vested interests becomes incessant and scrutiny by lone voices can be ignored.

This is used consistently on HN to push bad ideas aggressively until its too late, and the fact that rarely does this meet technical scrutiny early on suggests a missing technical depth in discussions.

The problem you outlined does exist -- but it's forced by marketing teams and vested interests, not by a bunch of tech enthusiasts. HN's influece amounts to a drop in the sea.

I can't believe after 2 decades that browsers are still missing so many native elements - date pickers, menus, flyouts - how many of those have been written for the web?

The two things that annoy me the most having the page change layout as it loads (often causing me to click on something different than I was aiming at) and lack of responsiveness. Having the UI baked into an environment that was never designed for it makes the apps anemic and slow.

Google is the worst at this, where they take perfectly fine and usable desktop app (say Picassa) and then replace it with some janky, feature deficient, "web app."

They love their tools, and they aren't making the distinction between software and content.

So they're trying to use the hammer of application development frameworks to attach the zip-tie of content, which is better accomplished with a different tool.

And it sucks for the user. It sucks hard.

I think the excessive complexity often comes from imitating techniques in projects that are solving problems for different audiences at larger scale.

As an old-school web designer, I recommend Jeremy Keith’s Resilient Web Design — https://resilientwebdesign.com/ — to anyone who wants to make a good, fast, future-proof website.

It seems that the HTML5 proponents still need to learn that lesson.

HTML for content, plugins for rich media. I never saw a problem with that. But I'm probably getting old.

Yes, I am tired of everyone trying to shoehorn everything into an SPA. It shows developers who want to jump onto the hype-wagon without always thinking if the problem they're solving is appropriate for it.

For example:

Back-end renders page and something crashes - you get 503 error and you know to refresh the page or contact support or w/e.

Shitty web-app loads multiple components via AJAX, doesn't even check for errors, some components do not load, you have no idea what the heck is happening so all you can do is inspect the JSON response in the devtools.

On the positive side though: In 10 years you won't hear much about "web apps" anymore.

From a programming model POV, having the server only spit the necessary data for the new info required, and not the whole set together with GUI data, is a real simplification. Not to mention the fact that it is already the architecture you need for the other types of client (mobile and native desktop app).

Whast is horrible about this?

For things as simple as form validation, you need to resend the values that the person entered in case the form didn't validate. Then you end up piggybacking informations from one page to another in hidden type form fields...

If that doesn't sound crazy to you, then you should probably write "native" application again, it will remind you how simple life is when your client has the right to use its memory.

Afaik most modern websites load every single request with Ajax (often through things like Turbolinks) but it feels so passive that nobody would ever bother complaining. Also it always perfectly falls back.

They have been bamboozled by so-called "full stack developers" who want to add the latest trendy "framework" to their CVs. Customers are alienated, shareholders money is squandered, and managers who let this happen are asleep at the wheel

I haven't built a static website since 2005 and I seriously don't get all the contempt for spa's or dynamic sites. Horrible user experience? Maybe for those who grew up on static designs. If you do them right, which isn't even hard, they should be a much better experience, since you're not loading all the content at once.

Maybe I don't understand because there's a bunch of gripping and not a lot of, "here's why it sucks". Other than, "the web was intended to support static sites". Yeah, and computers were built strictly for scientists, so stop using yours. :)

If you're being even more trendy and have turned your entire back end into an API, you then have to wait for the javascript to compile, wait for the intial document complete javascript call, post off for the data, wait for the data, run a render and finally display what the person wants.

On your dev laptop with 16 Gb and multi-core and a local database and web server, that's fast.

For all your users, it's not.

And all that for what? In the context of this discussion, maybe a fancy user menu that could have been written in a couple of kb of raw javascript by someone with more than a couple of years of dev experience that would take a millisecond to compile and run compared to the 500ms-20s of having to wait for something like React or Angular or Knockout or whatever.

Also, learn to discuss.