291–300 of 328 posts
Earlier quoted context omitted.
It's not as fast as https://dev.to/ , which is an SPA. I.e. client side routing.
Good: it detects when you’re offline and displays a fun error page. Bad: this only works on every other click. Half the time the links just silently fail....
Earlier quoted context omitted.
That's conflating two different issues
It's the same meta-problem, though: modern webdev practices involving adding gimmicks for no good reason that introduce extra complexity and resource use, and then adding even more complexity and resource use trying to fix all the expected behavior and features of browsers that the initial gimmick broke... and doing it poorly.
That being said I challenge the assertion that they are used for no good reason.
- Custom fonts are used because they help shape a brand. Properly used, the choice of fonts communicates a lot (at a subconscious level) about the company or person behind it.
- Unnecessary videos unfortunately work (i.e., help grab and retain user attention). Not for me (quite the contrary!), but for the majority of people stumbling upon a company's website.
- Same for weird gimmicks involving animations and what not. I can feel them draining my battery out and it phisically hurts, but most people like them and take away the impression that "this is a modern person/company".
All in all, many website's primary goal is not to communicate factual information, but to capture user attention and/or communicate at a subconscious level, and gimmicky things work for that purpose :S
This may get downvoted to oblivion due to the HN bias against js. The correct answer is it all depends. Certain things are faster to do in JS. Certain things are faster as a page load. One has to profile and see what makes sense. There is a reason Atlassian is dog slow and trello runs circles around in terms of UI performance. The immediate Once you have a substantial amount of JS, and you’re an app site, which a lot…
So maybe this is kind of obvious, but the whole purpose of client-side scripting is to make the site more interactive, right? If your site is completely static, you shouldn't be using client-side scripting. If you're site is very dynamic and interactive, you should be relying a lot on client-side scripting. Imagine writing a video game for the web where every key stroke was sent to a web server and every video frame was retrieved from the server. That would be way too slow due to the amount of interactivity involved and the latency introduced by the communication with the server between every frame.
Earlier quoted context omitted.
Good: it detects when you’re offline and displays a fun error page. Bad: this only works on every other click. Half the time the links just silently fail....
For me, it always displays the "you're offline" page.
(Disclosure: I'm Carter's desk-neighbor at Triplebyte.) I think there's actually a middle ground where you can utilize some of the more modern techniques to actually do better than the pure static pages approach, while still using normal browser-based page navigation. As a personal challenge, I wanted to see what could be done about performance for a recently-launched side project: the Ultimate Electronics Book [1],…
For the love of god, please, never, ever do lazy image loading. As a user, I expect the page to be 100% complete when the progress bar in my browser disappears.
Earlier quoted context omitted.
> This may get downvoted to oblivion due to the HN bias against js. Now, come on. Very few people in here would say that js had no place in the web. A lot of people are against js when alternatives exist. Trello is an application, so js makes sense there. A blog article that doesn't even display when js does not load, that's where people have a problem.
It seems a large chunk of people would rather trello was built entirely out of html forms so you press a to make the card move to the left and then the page refreshes with the card moved.
A similar issue comes up with Google AMP: it's billed as a web performance move but it's regularly slower and the failure mode is that you don't see anything at all. That doesn't mean that the problem is completely intractable but the act of taking over a core function put the onus on them to do a less shoddy job.
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…
When I want to read an article, I don't need a "web application". I want a static page with the text and the pictures. That's it. Not a single line of JavaScript. And certainly absolutely no image lazy-loading nonsense. If my data is that limited, I'd disable images myself in my browser settings, thank you very much. What I'm trying to say is that most of the web isn't really that interactive. It's mostly comprised o…
Yes, but the readers of the content are not the only customers the site is built for. The people writing and editing content are also consumers of the site. The article isn't (and doesn't have to be) interactive, but the CMS on the backend is. The advertiser's portal is. The reporting dashboards are.
Just like how Ruby on Rails is slow but we deal with it because it makes programming so much faster, dynamic websites are slow but we deal with it because it makes their administration so much faster.
Earlier quoted context omitted.
> If my data is that limited, I'd disable images myself in my browser settings, thank you very much. Yeah, because most visitors to most websites can and know how to disable images in browser settings. In fact, let me know how to do this in iOS Safari. Before you tell me to throw my iPhone and iPad in the trash, get an Android, root the damn phone, install F-droid, compile Chromium with patches, or write my own opera…
> In fact, let me know how to [disable image loading] in iOS Safari Given any browser, how do I reload a lazy-image that failed to load, without resorting to whole page refresh or diving deep into the Web Inspector? Most browsers have a context menu option to reload regular images, but they cannot and will never handle a bunch of dynamic block elements with background-image option.
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…
I'd count breaking my back button or otherwise mucking with my browser history as "los[ing] state". Maybe we have different definitions of "you" in mind.
Earlier quoted context omitted.
When I want to read an article, I don't need a "web application". I want a static page with the text and the pictures. That's it. Not a single line of JavaScript. And certainly absolutely no image lazy-loading nonsense. If my data is that limited, I'd disable images myself in my browser settings, thank you very much. What I'm trying to say is that most of the web isn't really that interactive. It's mostly comprised o…
>It's mostly comprised of content that is static in its nature Yes, but the readers of the content are not the only customers the site is built for. The people writing and editing content are also consumers of the site. The article isn't (and doesn't have to be) interactive, but the CMS on the backend is. The advertiser's portal is. The reporting dashboards are. Just like how Ruby on Rails is slow but we deal with it…
> Just like how Ruby on Rails is slow but we deal with it
Not all of us :)