171–180 of 328 posts
Although really, for longer-term listening, playing the stream in a separate media player is a better idea. But sites tend to hide their stream addresses, and this is also usable.
Earlier quoted context omitted.
It's not as fast as https://dev.to/ , which is an SPA. I.e. client side routing.
And it took me 2 minutes clicking around to break its idea of the page state. I am partially scrolled down the home page, and it just decided to deactivate scrollbars and the ability to scroll. A great example of how it's quite difficult to reimplement stuff that works perfectly well on traditional pages. (At least they seem to haven gotten rid of some of the dark patterns they had in the past, that's nice to see) ED…
I'd love if you can show me how to reproduce this bug.
I just don't have this experience with SPAs breaking. I actually have no idea where it's coming from.
Earlier quoted context omitted.
> I worked on a porn site that was basically an endless-scroll video gallery. So, if you're a horny teenager, you scrool down for a huge amount of time to find "the video" that will get you off... and you hear your mom coming up the stairs, Control+w (close tab), and when she goes downstairs again, you press Control+shift+t (reopen last closed tab), you're back at the beginning, and have to search for that video agai…
>you're back at the beginning, and have to search for that video again? That sucks. 1. browsers have some sort of cache[1] that allows them to restore closed/previously visited pages without doing a page reload. granted, it's not very reliable, but it'd probably work most of the time as long as you're not memory constrained or visiting too many pages in-between. 2. if the infinite load mechanism also updates the url…
(I still don't particularly like Discourse's implementation of infinite scroll because their custom scroll thing is awful to use.)
Earlier quoted context omitted.
> Because it's faster. The whole point of the article is that it's not true. It's not the only article that disproves it, and honestly, it's not difficult to notice it. Just go to any blog running off a static site generator; loading times of pure HTML webpages on good connection are so fast they whole thing outruns client-side page switches even if the page is already in memory.
> The whole point of the article is that it's not true. Only for the narrow condition of loading a whole page. A lot of Web apps make async request much smaller than loading the whole page: imagine deleting one record in a list of 50 items; the async response could be the HTTP 200 header alone. I think it would be useful for developers to separate web applications from web sites and consciously make trade-offs (such…
Imagine Software Engineers that actually engineered solutions - the use of small async requests would be a boon to everyone! But no one's doing this.
I know first hand of one company doing this nonsense with requesting a full JSON payload (describing the whole house that goes along with the proverbial kitchen sink), rather than requesting updates for the one property on the user's screen. I've proxy-sniffed at least two other, unrelated companies doing exactly the same thing.
Earlier quoted context omitted.
> The whole point of the article is that it's not true. Only for the narrow condition of loading a whole page. A lot of Web apps make async request much smaller than loading the whole page: imagine deleting one record in a list of 50 items; the async response could be the HTTP 200 header alone. I think it would be useful for developers to separate web applications from web sites and consciously make trade-offs (such…
Web apps making async requests should be making much smaller requests than loading the whole page - but they're not. They're loading a page and parsing out the "less than the page" bit to stick into the current page; or they're loading a JSON blob bigger than the current page to update the three visible elements on the page. Imagine Software Engineers that actually engineered solutions - the use of small async reques…
The current generation of less-experienced developers tends to default to building every project in React, even if there's no tangible benefit to accepting this complexity. It's unpopular to express, but the truth is that many junior devs don't know how to do it any other way. I don't blame them for this, because they literally haven't been doing it long enough to have mastered multiple techniques. Managers go with i…
We can’t blame junior devs using React and other frameworks to try to build more responsive applications. That’s where the demand is. I wouldn’t say it’s easier to build in these SPA frameworks nor harder. Attention to detail is something people recognize or learn over time.
As for whether an SPA is harder or easier, that's not really the relevant dimension. You should not be making technology decisions for your company based on what your new junior devs are comfortable with. They will actually level up faster if they are forced to take what they've learned and apply it to something they weren't working on in their nine-week intensive.
Meanwhile, there's nothing "easy" about React and co when you factor in the layers of abstraction and bikeshedding involved in a typical full-stack deployment today. Compared to when I learned, you suddenly have to also be confident with bash, git, docker, AWS, postgres, webpack, and the whole concept of a virtual DOM before you even start modelling your data or thinking about state transformations. Now go compare that to the original Rails "blog in 15" video and you'll have a hard time claiming that anything is easier. The drop in developer ergonomics over this golden era of JS tooling is stunning in its unneccesary masochism.
Earlier quoted context omitted.
Because it's faster. If you don't have to download all the content again, force the browser to re-render everything, then by design you just get the new content from the server faster, if you have to download anything at all. The idea exists since the introduction of AJAX. Furthermore, you don't lose state, which makes things much more simple. Imagine a simple image gallery. You just update the tag, update the URL wi…
> Because it's faster. The whole point of the article is that it's not true. It's not the only article that disproves it, and honestly, it's not difficult to notice it. Just go to any blog running off a static site generator; loading times of pure HTML webpages on good connection are so fast they whole thing outruns client-side page switches even if the page is already in memory.
Earlier quoted context omitted.
Because page reloads are jarring and discontinuous experiences. They run counter to a good user experience. That's not to say that every SPA is a good user experience, but just that a page reload is not part of the recipe for a good user experience.
HN uses the "old fashioned" approach of rendering everything server side and every link forces a page reload and I wouldn't describe the experience as "jarring and discontinuous". I'd rather have a fast full page reload than looking at a spinner while complex client side stuff does its stuff. [NB I really like React and when good SPAs are very very good - but a lot aren't].
I don't get client side navigation. It's a worse experience in every way. It's slow, often doesn't support things like command-click, it usually breaks the back button, and even if it doesn't it breaks the restoration of the scroll position. The only thing worse is a custom scroll UI. Why do people try to reinvent the most basic features of a webbrowser? And if they do, why do they always only do a half-assed job at…
Because it's faster. If you don't have to download all the content again, force the browser to re-render everything, then by design you just get the new content from the server faster, if you have to download anything at all. The idea exists since the introduction of AJAX. Furthermore, you don't lose state, which makes things much more simple. Imagine a simple image gallery. You just update the tag, update the URL wi…
Earlier quoted context omitted.
HN uses the "old fashioned" approach of rendering everything server side and every link forces a page reload and I wouldn't describe the experience as "jarring and discontinuous". I'd rather have a fast full page reload than looking at a spinner while complex client side stuff does its stuff. [NB I really like React and when good SPAs are very very good - but a lot aren't].
There's definitely parts that are awkward though. I can't see the context of your comment in my reply as it's on a completely different page for example. HN has never really been a great UI though, it used to be a massive set of nested tables that didn't render properly on a mobile, it has some tiny fonts and hard to click buttons, and has unliked comments just less accessible by lowering contrast. It's good enough t…