191–200 of 224 posts
Or we can say, they are implementations on how to achieve the same thing. The difference is performance.
A browser that implemented a few semantic tags (including and ), fonts, colors, and flexbox would be useful, secure, fast (even on slow devices/connections), and far easier to implement than the behemoths we have now.
Let the application web keep evolving, but specify a well-defined subset for sites that don't need all the features.
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.
But let's look into the point made by the author regarding the inspiring example of Apple's app store UX, and trying to aim for that.
We, meaning as an industry average, will not achieve that level of UX no matter the stack. Because nobody can afford it. It requires a team of top designers, interaction engineers, dev, QA, etc.
That's the problem with the SC valley mindset. They assume every web property has this huge team of top engineers behind them, and that this is a status quo, and applies to the whole web.
They have no idea what bubble they are in.
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.
Every time a web designer complains that a full-page refresh is "jarring", a bit of me dies. This is like saying a lightbulb turning on quickly is jarring. It's the expected, immediate behavior. If every lightbulb I used turned on with different durations and easing functions or flashed colors at me, or loaded a flashing placeholder while the lightbulb loaded, that would be jarring.
Why do you assume that it's just web designers? Have you ever shown a web app vs. a native app to someone who doesn't write code? Or just someone who has design sensibility? The lightbulb example is also not a good one. A lightbulb transitions between two states. An interactive application transitions between hundreds of states. Full page refreshes make each transition clunky and noticeable. Only programmers look at…
No, not just programmers. Also end users. It's a complete myth that the traditional link/page refresh method is jarring to users. It's perfectly normal and expected to click a link and to have it loaded in a reasonable time frame, without some weird transition in between.
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.
Earlier quoted context omitted.
Well, I think this is really hyperbolic. I think it depends on the application, and the consumer. And the web is a tremendous success. You should take a step back and look at how your entire life is affected by the web. It seems really, really off the mark to say that the web is not a success. You can criticize it, sure. But - you are using a computer 100% because of the web, not because of spreadsheet software. Now,…
"I exclusively use apps." Curious. Did you post this using a native app?
On my mobile I never access HN via the website, I use one of those apps.
Earlier quoted context omitted.
> your 10k npm dependencies Believe me, you're preaching to the choir. Nor am I advocating for every website to have an API. But unfortunately we part ways here: > The web is a success 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.
Well, I think this is really hyperbolic. I think it depends on the application, and the consumer. And the web is a tremendous success. You should take a step back and look at how your entire life is affected by the web. It seems really, really off the mark to say that the web is not a success. You can criticize it, sure. But - you are using a computer 100% because of the web, not because of spreadsheet software. Now,…
> 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…
Which debunks one of the critical advantages of an SPA.
The other is transitions. Which are never implemented because it's just too damn hard. Instead you get a spinner, 17 API requests (instead of 1 Ajax request), and a giant fragment of the DOM replaced whilst you lose your scroll position.
Earlier quoted context omitted.
Do you know of good SPAs? Sites that feel snappy even though they're SPAs. Most sites I visit that are SPAs are consistently slow so I've learned to make the same association: SPA = bad.
I understand what you mean. In fact, I think we should more frequently do the opposite: we should publicly shame slow websites ( cough new Reddit). Anyway, for fast SPAs, here is a useful comparison: the "RealWorld app" demo. I would urge everyone to look at the Lighthouse audits for these three implementations: React/Redux: https://react-redux.realworld.io/ Angular: https://angular.realworld.io/ Vue: https://vue-vue…