Maybe we could tone down the JavaScript (2016)

I recently came across a web site that allows one to zoom into the content (it's a mapping site). Only the designers just assumed that everyone would have either a mouse with a scroll wheel, or a touch pad. Well, I have neither. And the developers of the site suggested "oh, just install this piece of software that allows you to bind some keyboard shortcuts to simulate a scroll wheel" instead of, you know, providing two damn buttons to zoom in and out! ("But ... but ... but ... adding those two buttons would destroy the aesthetic of the site!")

> That's an implementation issue.

Right, but like I said, I'm not a purist about this, I just think that maybe SPAs should only be rolled out if the implementation actually works.

To circle back around to Google Maps, this is an app that had working links, and the introduction of more Javascript made them worse. So I'm not saying get rid of all Javascript, I'm saying that if you swap out `` tags and it results in broken browser functionality, that's a scenario where just using native tags would result in a better experience.

Twitter/Youtube/Maps are choosing to go down this route even though the implementation is worse. If they didn't have implementation bugs and navigation didn't break on sites like Youtube, and I could copy and paste links from Google Maps, and I didn't have laggy text input on Twitter -- well, then I wouldn't be complaining about any of this.

It's not really about Javascript being bad, but we can both agree that if a company tries to rewrite a website as an SPA and it results in a more buggy experience, then they should hold off on that and they shouldn't just plow forward with the implementation anyway. That has nothing to do with SPAs in general being evil, but even the act of saying "a Javascript-heavy SPA solution should only be pushed if the experience is better than the normal one" feels like I'm saying something revolutionary, and I don't really get what would be controversial about this opinion. Only push a Javascript heavy solution if your solution works, if it results in more breakage than the site had before that solution, then the engineers are moving in the wrong direction.

I don't know if this is a controversial thing to say, but I would say, "only push an SPA if you don't have a bunch of implementation issues". And I think that's where sites like Youtube and Twitter are falling over, in those cases their implementations are either broken because of tracking or just complexity, or something -- but it would have been better for them specifically to have not turned their sites into SPAs, because they can't seem to get rid of the implementation issues and their older sites didn't have as many showstopping bugs or performance issues.

I agree with you that sometimes this kind of partial updating can result in great, quick apps. But in practice, Nitter is faster Twitter is for reading tweets. So if I go to Twitter and I'm not signed in, and I'm just reading Tweets, that's an experience that Nitter is just flat-out better at providing in a more performant way. So it's not that all SPAs are evil or that they should always be avoided, but clearly in Twitter's case the introduction of an SPA didn't make the site faster or better, the low-JS solution ends up outperforming it on multiple key metrics.

Minor improvement; a rebuild queue. Workers scaled to platform capability (or just one). When a worker fires, scan the queue for other requests for the same content and use the freshest version / mark the future requests completed when the refresh finishes.

Whew, you need to try some Dhall then. Types, functions, imports all in a non-Turing-complete configuration language.

> No one asks if Excel or Hearthstone or Git or other desktop applications have progressive enhancement

I do! Yes, let's talk about native apps and documents!

https://news.ycombinator.com/item?id=21347067

https://news.ycombinator.com/item?id=21639043

https://news.ycombinator.com/item?id=23607320

etc...

----

Can you imagine how great it would be if nearly every graphical native app on your computer had a pure-text representation of its state that you could query/extend/manipulate? Or if you launched an app and it was missing a dependency and it launched anyway and just disabled a small amount of functionality related to that dependency? Some applications already kind of do this with their dependencies (Firefox will launch even if you don't have a GPU or video codecs installed), but it would be great if they did it even more.

The divide between applications and documents has always been a lie. Most (not all, but most) native apps are interactive documents, they are documents that change when you do something to them, and that are just styled to be displayed in 2D space instead of as pure-text trees. There are very few native app interfaces on my computer that couldn't render out to HTML or something similar. And it would be amazing if native apps were rendered out as pure-text XML/tree-based documents, that would be so useful. It would be even better if there were system-wide conventions for things like links/buttons inside of that tree that could be specified declaratively and that were user-inspectable. That would be a big improvement to accessibility and extensibility for application UIs. It would be like having CLIs for everything, but even better.

Applications are documents, and documents are often interactive. There is no actual distinction, it's just a gradient of how complicated the document is and how often it updates.

This is my pet-cause and at some point I'm going to finally snap, sit down, and write an extensive manifesto about it. Basically every single native app on my computer should work headlessly, should implement progressive enhancement, and should split out declarative representations of state that can be styled and intercepted by other programs.

Native app developers have gotten hung up on the bad parts of the web and the bad parts of HTML/CSS/Javascript (admittedly there are a lot), and it's caused them to completely miss the revolutionary idea that Unix already proposed all those years ago -- that most apps should output human-manipulable text formats that users can inspect, restyle, and pipe into other programs. HTML is the next evolution of that idea, and native developers are so hung-up on the details of the web that they've missed the broader picture and are stuck in the past in how they think about UX presentation. Even worse, they've started to push those outdated ideas onto the web; instead of taking a step back and trying to think about how to make more modular and more inspectable interfaces, instead of thinking about what a better implementation of HTML for native apps could look like, instead they argue that the web itself should do away with these concepts and just render out blobs of pixels compiled in WASM threads.