In google maps, gmail, and other places (where data shared between pages generally is loaded) I am very content with client site navigation.
As far as I see it really depends whether it is an app or a site that is being developed.
Browsers are pretty good at loading pages
241–250 of 328 posts
Re: Browsers are pretty good at loading pages
#242I 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…
> Because it's faster
That was the initial benefit. (Gmail, for example)
Then everyone starting using the client-side model as the de facto architecture for every new website and web app.
The old, "give a man a hammer" adage.
Like any tool, it depends on the job.
But sometimes a tool becomes so popular that it takes courage to choose not to use it.
"Err...well... sure I can explain why I chose to go with plain old HTML.. (gulp)"
Re: Browsers are pretty good at loading pages
#243This 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…
It's two years later, and I'm still waiting for those improvements in Jira. Until then Jira is a great case study of how not to do things in JavaScript, it's slow, it's inconsistent and I doubt the accessibility is very good. (It's also a great case study of how it doesn't matter how good or bad your app is, the success of your business doesn't depend on that)
We're definitely very slow on load at Atlassian, but our accessibility is actually really good. One benefit of a good component library (in our case React) is it allows mapping of accessibility labels fairly easily. Jira should be fully navigable with just a keyboard and headphones.
Re: Browsers are pretty good at loading pages
#244Earlier 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…
> Only for the narrow
> condition of loading a whole
> page
It is an interesting future we live in, is it the best one?
Re: Browsers are pretty good at loading pages
#245this is the first time I see mentions of react being difficult to optimize and I'd like to know more, is there any in depth quality article about it anybody knows on top of the usual light blogs a search finds?
No there isn’t because it’s BS. React is super easy to optimise. https://reactjs.org/docs/optimizing-performance.html
Re: Browsers are pretty good at loading pages
#246Earlier 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.
... 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. Unfortunately for us front end engineers we can't rely on the user having any internet connection let alone a good one. Most of the push behind static site generators is to get as much of the code necessary to display all the website in to your browser as fas…
Well. I can speak from a pretty solid experience here. I’ve travelled the US by train, the length of the UK by train and large swathes of Europe by train.
The site that tends to be the best to use is the ones that don’t take much to load. Connection tends to be spotty, you get bouts of “some” data and then you’re dry again for a while. If you can squeeze a page load in there it’s infinitely better than a half opened page.
Your first page load is -incredibly- important here. It’s the difference between a usable site and an unusable one.
The sites that work the best are the ones that do not try to do very much fancy stuff, because that fancy stuff only half-loads most of the time; leaving you to keep refreshing and hoping the spotty connection finally lets you bring in that 2KiB that will allow the page to actually load.
Re: Browsers are pretty good at loading pages
#247The 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…
Reduces server costs. Able to process data on client, including mathematical computation via We ebAssembley. Which in effect allows you to create "Web Apps," rather than just a news site, blog, ecommerce, etc... figma.com is an excellent example. Not to mention that SPA have been used for video game UI. Rather than building that system from the ground up. If your client's needs are to just display a static and do not…
Honestly, what do you think we did before the Facebook gods deigned to grace us with React? You understand that we didn't need SPAs to build everything, right?
Most of what's gotten better on the web has been about standardization and drastic improvements to EcmaScript. Unfortunately, we've taken all of these new toys and made sites that load slower, on average, on today's phones than typical sites did in 2009. The problem is far worse in developing nations where phones are many generations behind.
Don't get me wrong: I'm glad that React exists and if I was building Trello, it would obviously be an excellent tech choice.
However, there's exactly nothing simpler or faster about a React app vs a properly-cached SSR fronted by Turbolinks and a tiny framework like Stimulus for 98% of applications. I don't know how this became a sacred cow but at some point the Reactive defenders started reminding me of Scientologists.
People were really, really stoked about Java when it came out, too. One codebase that will run without modification on every device, they said.
Re: Browsers are pretty good at loading pages
#248The biggest advantage of using modern SPAs is that it forces the developer to build the backend as an API with which you can interact programmatically
The API between the SPA and the server is an internal implementation detail that doesn’t need to support interoperability or backwards compatibility. I see no reason to believe interacting with it directly is easier than scraping an HTML page. (In fact, I’d expect it to actually be much harder and more fragile than scraping html in practice)
In my experience scraping both, APIs have tended to be more stable than the structure of HTML pages. I'd guess this is because there's an incentive to keep your API stable (a breaking change for my scraper is also a breaking change for the front-end), whereas there's basically no reason not to rewrite giant chunks of the HTML to accommodate a design change.
Re: Browsers are pretty good at loading pages
#249Earlier quoted context omitted.
It’s certainly possible to write good client side code, I’ve worked on teams that really care and are given room to do it (because they were able to demonstrate its worth after so much effort.) and on teams that don’t. JavaScript, as she is spoke, is just an awful language. It has brilliant ideas and if applied correctly could make everyone’s lives better but that’s just not how it’s used.
So your argument is that many teams don't care and do a bad job and it is the fault, somehow, of the language they use?
It's a powerful argument. Defending client-side rendering here (or SPAs) is almost no-true-Scotsmanish. It is technically possible to do a good job, but it's almost never done. Yours and sangnoir's teams may care about performance and do actual software engineering - but it doesn't help me much when my bank doesn't do it, the places I shop don't do this, big sites like Reddit don't do this, and seemingly none of the SPAs I've visited in the past 5 years do it.
Re: Browsers are pretty good at loading pages
#250Earlier quoted context omitted.
Sure, web performance is an afterthought at many places and the more people work on a certain project the worse it gets because each team has its own motivation, but they all have the same target to shoot at. I think there's a connection between the organizational structure and the bad frontend experiences and this is almost always overlooked in these discussions. This is no surprise of course, we only see the crappy…
SPAs are the worst, because companies deploy them to avoid separation of responsibilities and turn every employee into easily replaceable "full-stack developer". Unfortunately, a lot of people write terrible applications regardless of chosen technology. When this happens to purely server-side applications, the company is forced to optimize them to keep the hosting bill low — a positive feedback loop in action. SPA ap…
> companies deploy them to avoid separation of responsibilities and turn every employee into easily replaceable "full-stack developer"
SPA-s are much-much harder to develop if more teams are working on it. So your first sentence makes little sense.
> companies move everything to client-side in order to reduce Amazon bills
This is never the reason why it happens. Seriously? The cost are not saved, just moved around. SPA-s are developed because they could provide a much better UX. As a side benefit, server side development becomes simpler by providing some REST or GraphQL API. You don't want to be in a place where tens of thousands of lines are generated backend side by backend developers.
> client-side scripts are poorly optimized and contribute to global warming by causing hundred thousands machines to spin up their CPU fans.
I appreciate your sense of humor :D