Ask HN: Anyone getting sick of all the 'web apps'? | Hacker News Reader

Ask HN: Anyone getting sick of all the 'web apps'?

181 pointsCM30136 comments

Or at least, attempts to make simple content based websites work more and more like apps?

Because it seems every site that's gotten a 'redesign' in the last year or so seems to have become some clunky, awkward to use 'app' like thing with dynamic content loading where simple text would do just fine.

Reddit's annoying enough like this (thank you mobile 'loading' screen for every page), but then you've got stuff like Wikia where it seems every single page is loaded via AJAX. Then breaks horribly because it gives me 404 errors 9 times out of 10.

Do these companies not realise how awkward these new designs are to use? Or that if you're not making a social media site, your site doesn't need to load like one?

View on HN

I'm going to go against what appears to be popular opinion and suggest that this reeks of a "back in my day..." complaint.

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.

I think the point here is that websites where you come for information should give you just that - information, and not to get in your way. Let me dissect the problem into parts: * Bloat - not only HTML, but also CSS, JS, a ton o plugins, social media buttons etc. This all slows things down and often obscures the content - that is the very reason you came to visit the site. * Poor UI decisions - with plain ol' HTML a link is a link, an image is an image - when you try to change an HTML document into an app you have to mix different roles. * User-hostile decisions - popups and similar, lack of permanent links, etc. In vanilla HTML you didn't have these.

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

does pragmatism really fade away in the face of progress?

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

I found a presentation a while back that covers "website obesity"[0]. It puts some quantifiers on the problem you're describing.

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

I think the Youtube redesign idea is to use something like polymers or whatever they are called. They are a Google technology supported in Chrome, but since other browsers need to use some clunky and superslow javascript polyfill Chrome suddenly feels like the fast browser.

Wow, this is evil.

Not really. Other browser vendors can implement the standard too, which is called Web Components.

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

I don't think that assumption was unfair. The way that the previous comment was framed, Google implemented this so that other browsers seemed slow. Those intentions seem pretty evil.

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.

It's still a draft i think.

you're right, they used Polymer and Material Design for the frontend in combination with the spfjs framework, which was introduced in 2014.

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

https://github.com/youtube/spfjs

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

> Users want websites to be fast and less annoying.

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

You would think so. I mean, that's obvious, right?

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.

Doesn't that have to do with overengineering more than anything? Most of the Javascript on a modern website is pretty much superfluous I'd say.

I'd also say that the JS and its burden on CPU, RAM, and battery, is also pretty trivial compared to rich media consuming more than a few MB's off a user's mobile data plan. Many people consider 1 MB to be around the upper guideline for bundle sizes; 2 MB of JS is considered quite big.

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.

Is JS the problem though? For really heavy apps, sure, but many people consider 1 MB to be a good upper threshold for bundle sizes.

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 why are we loading even 1MB to display 2K worth of text?

If people only wanted 2 kb text pages, it'd be a different story. But rich media is often what people want, so it makes even an information lookup on native Yelp expensive. Once you bring in rich media, 1 MB of JS is very minor, and JS can be used to optimize your rich media downloading.

Sure, but why do I need that crap on pages without rich media? And why do I need to wait for my browser (since it's on a computer other than the latest model iMac) to spend 20 seconds rendering that mess of JavaScript before I can view that content (text OR rich media), when it could display vanilla HTML faster than I can blink?

I'm with you. You'll frequently see news stories with 3-5 MB of junk to augment a < 50 kB piece.That's more information than all of published human writing before 1800. Sorry, but that's stupid, and looks bad. Yes, a good chunk of that is ads, but a lot of it is loading all of two versions of bootstrap so you can use one class and similar silliness.

It's actually often slower. Depending on how much functionality is written in JS and how many API calls you are making. Some single page apps out there can bring my MacBook Pro to a halt with their bloated spaghetti JavaScript and tons of AJAX calls everywhere. Rendering dynamic HTML on the server is often faster.

The problem is latency, which actually will get worse as bandwidth increases.

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

Google developers definitely know there's a problem https://www.youtube.com/watch?v=4bZvq3nodf4

> There's always been poorly-written software, poorly-created websites, bad UIs, bad UX, etc...

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.

Don't forget we used to have flash back then. It wasn't pretty.

Yeah, but basic news or discussion sites didn't use Flash. In fact, the vast majority of sites didn't; or only used it for games or video - i.e. use cases that called for it.

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

The problem is the bad stuff seems to be the norm. I wanted to use Patreon's embed code on my site. The embed loaded megabytes of JavaScript to show a button. All the button does is take you to my Patreon.

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.

> The embed loaded megabytes of JavaScript to show a button.

They're probably hooking into their analytics platform.

Yesterday I was thinking about the same issue that OP outlined. I tend to agree that all the SPA hype and all the additional levels of abstraction on top of HTML+JS+CSS need to go in favour of lightweight readable dead-simple sites, this is what the web is meant for in the end. For apps we have apps.

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 tend to agree that all the SPA hype and all the additional levels of abstraction on top of HTML+JS+CSS need to go in favour of lightweight readable dead-simple sites, this is what the web is meant for in the end. For apps we have apps.

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.

This is a true description of the current situation. Question is: is it a good situation?

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.

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.

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.

I think the situation we are in with the web proves that the distribution system with the lowest friction and that allows points of friction to be smoothed out in iterations over time will win.

But the friction in Web apps is not smoothed out. It only becomes worse. More and more megabytes of JS that nobody knows the purpose of -- or if they do, they are bummed as to why must they be 1.5 MB minified.

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

Things aren't improving.

I agree, but IMO that is a people problem, not a platform problem. I'd say there are 2 often conflicting goals in UX:

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.

I can completely empathise with this, and the distinction between website vs web-app doesn't seem to be clearly defined for most people, outside of software. I often find myself explaining the difference using Google Docs, vs BBC News to illustrate the distinction.

In reality there are also two kinds of end users. Those who want websites to perform like apps and those that want them to be focused on readability and (mostly text) content only.

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

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.

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.

> For apps we have apps

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

I wouldn't mind going back to the simple web pages of yesteryear, stuff you can write in a simple text editor. Black text on a white background, blue underlined hyperlinks that turn purple when visited, simple formatting that respects your browser's default fonts and pages that degrade gracefully to slow connections and low-resolution devices.

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

I have written all most all my Web sites and their pages with vi since the start (for me some time ~1993 commercially and connected to the live non-academic Internet, before that at uni), though I have just now started to play with CSS seriously. Wouldn't want to rush it.

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

No, they absolutely do not suck. They're beautifully functional basic HTML, straight-forward with no excessive fluff :-)

\o/

> For apps we have apps.

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.

I'm going to go against the tide of opinion and say a good app done well does add to the user experience. And what really constitutes an 'app'? Does the voting up/down experience in hackernews constitute an app because it doesn't refresh the page? A site can have varying amount of dynamic content so there is no hard line.

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

> Especially if you allow it degrade gracefully.

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.

This too shall pass (said with fingers crossed).

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

Well, we can thank companies like Google, and the powerful role that email ended up playing in our world, for the simple fact that web-based email took off, and therefore email clients that ran on web pages became not only important but also the key to the bottom line for some companies. And when those companies then invested billions of dollars into browser technology to make it an even better platform for their content, and increased the power of JS and what a browser can do, then writing complex applications became inevitable.

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.

Because animated transitions make the manager proud.

I hope you're not serious. When we talk about an SPA, we're not talking about how it looks or animates. We're talking about functionality, really.

I am 100% serious, speaking from two decades of webdev experience for >10 employers. When people advocate SPAs, they usually talk about responsiveness to the user, increased engagement and other such things, but the true underlying reason is always the same and it's exactly what I said. Hard page reloads make the manager feel like their product is janky. Animated transitions make the manager proud. Every manager.

Do you remember back in the older days of IE4/IE5 there used to be filters, page transitions, DXImageTransform (do I recall it right?)... a totally cool tech and a selling point.

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

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.

1. Advertisements.

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.

Getting sick of all the bloat and dynamic-for-dynamic's-sake designs, definitely. Also getting sick of companies using "cloud computing" etc. as a smokescreen to justify siphoning your data off into their servers for analysis and resale when they could easily do the processing locally.

Our 'app' runs on a radiator valve (!) and absolutely our design / privacy philosophy is that we can do a decent job without data leaving the radiator, noticeably better if we can share it within the house, and only after that and with consent, a little better still with some 'cloud' help!

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.

I'm seeing that some of this is being driven by web developer shops who are telling clients that this is how things must be done. I was sent a 600MB chunk of crud today to be hosted that required a full lamp stack to build a web app that could have been done very nicely by a four page static site that worked well on mobile. This is has insane. These design shops (not all) don't care about building sites that help their customers, they only want to produce eye-candy that they think makes their portfolios look cool.

When you are a hammer everything looks like a nail. Sometimes it may just be ignorance at play, I used WordPress before I handcrafted a static site.

> they only want to produce eye-candy that they think makes their portfolios look cool

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.

Enjoy what you have now. Soon enough blogs will be rendered via WASM onto a canvas bitmap using a full embedded UI something like QT.

That capability actually sounds pretty darn cool to me.

Via emscripten. Slow, but it does "work".

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

Just because you can, doesn't mean you should.

And just because you shouldn’t doesn’t mean it’s not cool.

Wait for the first time you'll want to copy a text snippet form there.

That would clearly be a violation of both the terms of service of the site (and thus the CFAA) and require breaking the embedded DRM of the site, a federal crime under DMCA part 1201. No one would be so reckless!

Yeah, but why should we welcome a world were web sites become read only PDF?

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.

I look forward to the resulting RAD tools and OO frameworks, as we reach the end of our journey back to the '90s and another generation learns (or fails to learn) all the same lessons, but now with ubiquitous ads and tracking for the online-generation version.

Heh. PowerBuilder WASM edition.

It may happen sooner than we all think.

> as we reach the end of our journey back to the '90s and another generation learns (or fails to learn) all the same lessons,

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.

Personally, I'd love this (except without any dependence on Qt).

A couple of weeks a go there was a similar discussion here in HN related to this. I remember a comment I really agreed with, that contrasted the current web "apps", and how the expectations around quality and features have been botched, compared to 2000's desktop app: A desktop app you expect to have stuff like drag and drop, to use a relatively small amount of memory, to save a file that you can transport somewhere else, you expected them to work 20 years after the first use (some even 30 years, with DosBox and the like).

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

That 'for some reason' that made the web win was one thing: search. The user interface of being able to type a few characters or a word in the arena of what you want and to be actively doing what you wanted to be doing a moment later is something people very much want. And desktops never provided it, so web won. It's as simple as that.

I suggest that there was something else just as important: desktop apps never solved the "convenient installation and maintenance" problem.

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.

Completely agreed!

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.

There was an article recently on HN with a clickbaity title "It's time to kill the web" but its core argument was that HTTP is a document delivery protocol and not meant for building applications, and I think that is the main reason why we are seeing an explosion of frameworks and poor app quality.

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)

The real problem is that demand for websites and web apps has grown faster than the supply of skilled developers who can build them properly.

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.

I work at a place where our websites should definitely be about informations and accessibility. But the pression to use SPAs in order to "be cool" is so strong, almost nobody questions this decision.

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.

> Do these companies not realise how awkward these new designs are to use?

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.

So you're saying marketers can't "fathom" basic concepts about content, but are also technically competent enough to be the decision-makers when it comes to the technology stack?

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

I guess the marketing merely go to conferences and have their heads trivially washed up with the newest buzz stuff. See our numbers are tumbling and X is doing that (cool new site design), coincidence?

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

Marketing builds brands, manages products, distribution, CRM and communication.

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.

content really does outweigh any cutting edge buzzword, 4chan is stuck in 2003 and it doesnt stop it from gaining users.

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

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.

Reddit's mobile page is frustratingly technically incompetent, especially as if you switch to desktop it works instantly.

Somebody did a performance audit on it 2 years ago: https://github.com/reddit/reddit-mobile/issues/247 It looks like nothing has changed.

It’s telling that their mobile experience starts with an advert to “Try the app, it’s better!”

I was thinking that they did it on purpose to push the native app...

I'm not using web apps at all. To be honest, I thought they were a fad and am amazed that they are still deemed successful and trendy. I haven't seen a web app so far that would even remotely match a corresponding desktop application in terms of quality and features. But I guess times are changing and people are happy with less quality, as long as its shiny and new.

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.

I don't run anything other than stock apps on my phone.

The desktop is a different world.

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

There are some decent electron apps like Atom and Slack.

> Most web apps violate basic user interface design and don't even have working keyboard shortcuts.

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.

Monetization - content websites turned into apps because the business is data collection.

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.

I'm sure sick of anything web-based that's not a form app (for which the web works fine -- e.g. ticket purchasing, taxes, posting, etc) -- of course regular content presentation websites are OK too.

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

I've been sick of web-apps since they became a thing. We should have built nicer visual designs on some weird combination of Delphi and X11 or something vaguely like that.

I've been sick of web-apps since they became a thing, too.

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!

What sort of GUI library/libraries are you using?

Depends on the use case, but generally right now it goes like this: if it can be done as a high-density Games/Games-like GUI or some kind of interactive media/content display, which 99% of modern apps are: I use MOAI. If it has to be a Business GUI with normal looking things for whatever platform: Haxe. If its a quick tool for lab/workshop: libUI.

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

I think I may have to learn Haxe. Which MOAI are you referring to? The library I found was a mobile-games engine.

MOAI SDK: https://github.com/moai/moai-community

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

I've never liked them from the beginning. HTTP/HTML/CSS were created for making static documents. The problem is convenience. Convenience for users, convenience for developers.

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

The lack of self awareness is glaring. This is pushed entirely on sites like HN with endless hype and resume driven development.

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.

I mostly agree with you but you're being too harsh on HN. It barely influences anything at all.

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.

One question I have - should we keep building apps in the document model (http / https), or finally create a true static document model and add a separate app layer?

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 reality is that that lightweight or even hand-coded apps and sites are faster, more semantic, and easier to maintain, and often look less cookie-cutter. But you don't get hired for knowing how to create a great web app with HTML, CSS, a server-side language, and a little JS or jquery for flavor. You get hired for becoming an "expert" in something that has only been around 2.5 years and is at the inflection point in the hype curve. What you're seeing is the result of resume-driven development.

Yup, and then you lose me to some other site.

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

The trouble is that developers have great tools for building actual web applications. You know, things like Trello or Google Docs or whatever that are actual software hosted in the browser.

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.

Yes, and for quite a long time.

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.

At least Flash developers already realized that Flash was not meant for content delivery.

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.

You are not getting older, (in fact you are getting older) it is just that the http protocol was never designed for this and we are paying the price. I find your approach very rational, it is something that was lost in time.

There used to be a time when SPAs were meant for real web-apps (as in, things like the Admin area of your PayPal account) and everything else lived happily as website pages.

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.

You are correct, but it is not because of concept itself but rather because of lazy implementations.

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.

Amen brother. Unless we want to talk about "apps" in general that - in 95% of cases - could be mobile-optimized web sites.

lol. It is just in the process of getting worse. Soon you'll have "all the container apps", developers even more removed from the actual administration and even less ability for you to interact with what other people do.

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

btw, http://www.reddit.com/.compact is a far superior mobile UX than their official mobile site (and make sure you click "No" to the banner enticing you to try their mobile site when you first land)

You can also access it from https://i.reddit.com/. The problem is there are so many inter-reddit links throughout comments, sidebars, wikis, and submitted links that you usually end up getting booted into the newer interface at some point.

Well, if you look at the declining numbers of downloads for native apps yearly, you can see why big companies would want to switch to progressive web apps eventually. Web components and the focus on components in a framework like Vue.js make sense in terms of UI. I think the tooling has a lot to do with the spreading of the concept of the SPA also.But I agree, a lot of sites are jumping on the bandwagon and shouldn't. You look at a site like Craigslist, that never changed and it still is a piece of art /s Anyways, I'm just a noob so my opinion is worth shit... As a sidenote, working with webpack and vue.js is amazing (no, I'm not a hipster...)

Web apps never feel right to me because they are so obviously not of the platform. I get the same feeling from some cross platform widget toolkits. Yes, the application may be cross platform, but it doesn't feel native anywhere.

Reddit's mobile website is objectively worse than their desktop website on mobile.

LinkedIn is horrible as well. Their chat feature (on mobile web) is unusable. The Send button goes further and further down the screen as you type until it disappears... permanently. No amount of refreshing will bring it back. They took the app paradigm and ran with it until they created a broken website when in fact, a single textarea and a button would have sufficed.

I don't think the "graphical design" aspect should be the only factor to consider (at least for the general trend, not for wikia in particular). SPA issues should be balanced with the horror that server-side session data is. Trying to rebuild the client-side state every time after each answer.

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

> the horror that server-side session data is

Whast is horrible about this?

Well, for once it means resending over and over the same information on every page, it's just a waste of bandwidth. Then it makes sharding the server more complicated, because you need to make sure the request goes to the correct server (or you have to use a special DB just for that such as redis).

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.

I don't quite understand the relevance here of the server. An SPA may or may not have a tight interaction with a server. Most of the time, an SPA to me is mostly living as a browser process, with occasional interaction with a server, but that doesn't have to be the case. If it is too tightly tied to a server, then it's not really a true front-end application, it's more like a web site in that regard. SPAs are usually more than a window into a server, they are a dynamic application unto themselves.

I believe there's gotta be a middle ground. Web Apps (and Progressive Web Apps) should be treated as the new standard because they take the best part of web and enhance it with patterns and features that we already know works thanks to mobile. Now, I agree that most implementations are very bad and need to be improved. I think the whole "javascript framework" situation is getting very close to total mayhem and I hope somebody will figure out a way to create web apps that have both functionality and simplicity to user and developer

I agree the mobile Reddit is awkward to use and a horrible experience. However i dont think this is a very big issue. Sure everything started to look like Bootstrap in the last years, but IMO most people did it right without making UX worse.

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.

No, in my experience such websites are faster to navigate.

Pushing UI rendering to client side and other "rich client" properties stress the servers less, so it's an advantage for the app provider.

Generally web apps perform better because you load the app once and it gets cached by the browser. The ajax calls to get content reduces the data that you need to transfer. It also forces you to create APIs and reuse them and on the frontend side it provides much more flexibility to modularize and reuse components compared to the clunky widget interfaces available in server side frameworks.

404s are irrelevant to the fact that the site is using an web app or not. 404s exist for the longest time and they're as common in both cases.

kids these days

Do these companies not realise how awkward these new designs are to use? Or that if you're not making a social media site, your site doesn't need to load like one?

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

One reason I see is that there just is not enough of good enough content and people seem to want to obscure things just because they want to hide the fact that there is not anything worth checking / consuming.

I see a lot of folks complaining, but the reasoning is completely blown out. "I hate spa's because they have a 50 mb library behind them". Honestly I'd like to see an example of that.

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

A SPA generally has to initialize and hook everything up.

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.

http://idlewords.com/talks/website_obesity.htm

Also, learn to discuss.

Reply on news.ycombinator.com