131–140 of 224 posts
Earlier quoted context omitted.
The author isn't just a React apologist... Nothing about TFA indicates that its author is a React apologist. Do those even exist anymore?
Did I miss something and the many people who are willing to defend React suddenly disappeared?
> The fact that we can do server-side rendering and communicate with databases and what-have-you using a language native to the web is a wonderful development. The author isn't just a React apologist, but also seems to want javascript everywhere. So much of this debate - sever side rendering, etc. - has to do with the inefficiency of DOM. Mobile and desktop UI toolkits aren't DOM for a reason. They do application UI…
Quite the contrary.
The author has criticized React openly _many_ times.
He is also the creator of Svelte which mainly aims to reduce the amount of JavaScript web apps are using compared to React, jQuery, etc.
SPA tech is a good thing for web sites that have little appy parts (like checkout processes, or maps). I'm not saying for the entire website, but just little focused parts. Can you imagine going back to (the old) Yahoo Maps now that Google Maps exists?
Are SPAs good for entire websites (like the new reddit?) Personally I like the new reddit over old reddit. But this is where your users are highly relevant. If you don't listen and choose SPA for millions of users of the public, you will probably get Feedback. You might be lucky and only 10% hate it, but it might explode in your face if that's a key 10% that encompasses influencers.
> When I tap on a link on Tom's JS-free website, the browser first waits to confirm that it was a tap and not a brush/swipe, then makes a request, and then we have to wait for the response. With a framework-authored site with client-side routing, we can start to do more interesting things. We can make informed guesses based on analytics about which things the user is likely to interact with and preload the logic and…
Yes, this. I about fell out of my chair reading this paragraph. In these discussions, I find defendants of these SPA designs to almost always point to vague points about "rich UI" or "highly interactive", or make up complete hypotheticals like this example of pre-loading likely-to-be-clicked links. Show me the code. Show me the crazy-fast link-click-predicting website that does this and loads faster than, say, Hacker…
https://hn.svelte.dev/ is a Sapper implementation of Hacker News. It uses the preload-on-hover/touch technique described in the article. In my experience it does indeed feel faster than Hacker News, despite basically being something I threw together one weekend
SPA as the status quo is a myth. It's a Fermi paradox. Where are they? Almost nothing of any importance is an SPA. You'd think that if they have such superior experience, they lead to superior business metrics, thus they are everywhere. Asides from true app-like experiences like Gmail, Spotify, the like, they're nowhere to be found. Not in places of significance. It's 2020 and Amazon continues to be old school page refreshes. Last time I checked they're doing quite OK. Even big parts of Facebook, the poster child of complex interactivity, continues to do full page refreshes in big parts of the experience.
Instead, SPAs are a startup default, not a web default. Big difference. And the way most are implemented, they don't live up to their potential benefits, instead deliver UX that is even worse than static:
- breaking back buttons - breaking scrollbars - rendering things that aren't interactive
These things don't have to occur, they can be solved in an SPA, but they do occur a lot in the wild. This matters. We live in the real world.
As somebody else here already mentioned, the article takes a completely wrong approach. It assumes some binary choice or outcome. The original point instead was that the web is not a single thing. It's a huge thing where different stacks are to be used for different use cases. This point is largely ignored, instead it is implied that SPAs should simply solve such use cases better, whilst continuing to be a default.
On the particular point of SPA links being typically faster/smarter: there's about 500 drop-in solutions to speed up static links. Which are usually not needed, because the point of such links being bad is overstated and lacks any user evidence. See my earlier remark on virtually all major websites using plain old links. They wouldn't if it was so bad.
Finally, a huge part lacking in this discussion is the accessibility of web development itself. The SPA web is an engineers web, it requires advanced programming skills, infrastructure, increasingly complex tools chains, and so on. If this was to be a true default (luckily it isn't), it would lock out the vast majority of people wanting to contribute to the web.
It's sad to see this sub culture of hardcore engineers with Macbook Pros thinking they own or represent the web or web development.
This author seems to think the only competitor to react is other js frameworks, when in fact most of the web's largest sites work just fine with small amounts of what he calls 'artisanal js'. You probably don't need your js framework, your 10k npm dependencies, or your complex mix of server and client side rendering. Not every website needs an api and clients to consume it, and not everything needs to be an app. The…
> your 10k npm dependencies Svelte projects do not put 10k dependencies in the final bundle. In fact when using Svelte you won't need many dependencies you typically need when using React: - State management (MobX, Redux, etc) - CSS stuff (classnames, CSS in JS, etc) - Animation Even on a simple use case like a synthetic benchmark Svelte is still the absolute leader in start-up metrics: https://krausest.github.io/js-…
Earlier quoted context omitted.
>I'd love to see more mindshare go towards building libraries that are drop-in/"just add water" progressive enhancements for static sites. Sounds like jQuery plugins. Seriously though, I wish for a similar thing without the baggage. Maybe there needs to be a common interface defined for such "just add water" libraries.
There was/is so much that was genuinely awesome about jQuery. I still remember fiddling around with my blog as a teenager and being blown away by the DataTables plugin.
Earlier quoted context omitted.
Yes, this. I about fell out of my chair reading this paragraph. In these discussions, I find defendants of these SPA designs to almost always point to vague points about "rich UI" or "highly interactive", or make up complete hypotheticals like this example of pre-loading likely-to-be-clicked links. Show me the code. Show me the crazy-fast link-click-predicting website that does this and loads faster than, say, Hacker…
> Show me the crazy-fast link-click-predicting website that does this and loads faster than, say, HackerNews. https://hn.svelte.dev/ is a Sapper implementation of Hacker News. It uses the preload-on-hover/touch technique described in the article. In my experience it does indeed feel faster than Hacker News, despite basically being something I threw together one weekend
I think one nuance is lost on both articles: web-development is generally stuck in a system where all the incentives are wrong. - The developers want to prove themselves with a new technology - The site owner wants to make money, so adds are required - The website needs to "verify identity" to cut down on fraud, so invasive trackers are added - The finance team wants to cut down on infrastructure costs, so they want…
Just why can't we improve the user agent instead of turning every website into an app that does its own thing to provide the UX?
For example:
> We can kick off requests as soon as the user first touches (or hovers) the link instead
There's no reason this couldn't be built-in to the user agent. It could very well pre-load pages before you even start scrolling around, or it could start loading as soon as you hover, or it could start loading as soon as you click. I get to decide, because I can configure my UA. People on data caps will be happy to turn it off. Meanwhile you can optimize your ugly slow service so that it processes requests fast enough that you don't need these hacks..
> We can provide better visual feedback that loading is taking place
Usually I get either crickets or a spinner or something went wrong if it's the javascript doing this. Again I think it is the user agent's place to give the user visual feedback (according to their configuration). I'd turn them off, because they're not useful. I'd rather have you spend time making your ugly slow service faster than implementing transition animations to "hide" the latency.