81–90 of 224 posts
> 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…
I don't think the DOM is the bottleneck as much as JavaScript is.
Genuine question: are smooth page transitions really worth all of this? It seems that page transitions really are the main reason given for using JavaScript-everything for sites and simple applications that otherwise could have been built with some fast loading HTML and a couple of POST forms.
How many sites actually do this? And how much additional bandwidth (and battery life for mobile devices) does doing this consume?
> We can provide better visual feedback that loading is taking place and a transition is about to occur. And we don't need to load the entire contents of the page — often, we can make do with a small bit of JSON because we already have the JavaScript for the page.
In my experience sites that do this are almost universally slower and less responsive than sites that just use normal links. Maybe that's just confirmation bias and I just don't notice it as much on sites that do it well, but a particularly egregious example of this is Reddit's current mobile site vs their old i.reddit.com mobile site (which I use exclusively (despite it missing a number of newer features and having a lot of minor bugs the newer site doesn't) because it's way way faster).
Earlier quoted context omitted.
> The web is not a success. It's dying. Consumers vastly prefer native apps — one recent study ( https://www.mobiloud.com/blog/mobile-apps-vs-the-mobile-web/ ) tells us that 90% of mobile time is spent in apps vs 10% in browsers. Does that really mean anything other than you can do more things with mobile devices than just browse the web? I might use WhatsApp on my phone, draw with Procreate on my iPad or play games.…
Why do any of those things need to be native apps, rather than instantly-accessible, no-install-required URLs that come with all the protections of the web's security model?
Earlier quoted context omitted.
> without re-hydrating tens of megabytes of JS for each tab you load You'll be taken more seriously if you don't engage in meaningless hyberbole. You could recreate the open-the-reply-page-in-a-new-tab behaviour of HN (with the context-preserving JS enhancement for the non-middle-clickers) with a few kilobytes of JS if you're doing it right.
> You could recreate the open-the-reply-page-in-a-new-tab behaviour of HN That is the crux of the problem. Why is there this obsessive need to recreate what is already available? > with a few kilobytes of JS if you're doing it right. As experienced with PHP developers in the dark ages, that never works. It will be a choice between easy and incorrect or difficult and right. The majority will never do it right for vari…
For exactly the reasons stated: to both support in-line reply without the jarring page refresh, and to be able to open the reply form in a background tab.
And I think what Rich wants/is working on is making it both easy and right, because indeed, otherwise it will never happen.
I was disappointed to find that this post falls into the same pit a number of these defences of the modern web fall into - creating a false dichotomy between "literally no JavaScript whatsoever" and "a framework-authored site with client-side routing". None of the features mentioned in that particular paragraph - user interaction analytics, preloading data and content [on link hover], transitions, avoiding full page…
As discussed on a recent thread ( https://news.ycombinator.com/item?id=23137324 ), there are a variety of nice frontend tricks to make a server-rendered site feel nicer (LiveView, TurboLinks, Livewire, instant.page). I'm a fan of these kinds of solutions. For my 100% static website, https://instant.page does make it feel instant. TurboLinks feels a little "heavier" and has a more complex interaction with other fronte…
> 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…
Maybe reinventing the whole damn car on canvas isn’t a great idea either. I bet that the keyboard isn’t the only part that doesn’t work.
Flash was hated for this reason too: Breaking affordances. Imagine everyone reinventing their own UI framework on each app.
> 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…
Apart from "apologist" not really being a term conducive to constructive discussion, I think, the author is also the author of one of the main competitors to React (Svelte), and has often and strongly criticised it. (Which is not to say that he hates it, but just to point out that "apologist" isn't really correct, and thus that it could be that the article is triggering some defensive reflexes that might not be entirely justified.)
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…
I was disappointed to find that this post falls into the same pit a number of these defences of the modern web fall into - creating a false dichotomy between "literally no JavaScript whatsoever" and "a framework-authored site with client-side routing". None of the features mentioned in that particular paragraph - user interaction analytics, preloading data and content [on link hover], transitions, avoiding full page…
As discussed on a recent thread ( https://news.ycombinator.com/item?id=23137324 ), there are a variety of nice frontend tricks to make a server-rendered site feel nicer (LiveView, TurboLinks, Livewire, instant.page). I'm a fan of these kinds of solutions. For my 100% static website, https://instant.page does make it feel instant. TurboLinks feels a little "heavier" and has a more complex interaction with other fronte…
https://github.com/derbyjs/derby
https://github.com/derbyjs/racer