I don't get 'SEO for free' argument. You don't SEO application, you SEO landing page and you don't want crawlers to crawl your app.
You probably don't need a single-page app
121–130 of 522 posts
Re: You probably don't need a single-page app
#122Earlier quoted context omitted.
I think old.reddit.com's interface is more user-friendly than HN's. Why should I leave the page to write a comment? Avoiding JS just for the sake of avoiding is just blind fanaticism under the pretense of being faster and more lightweight. (The new reddit redesign is a resource hogging abomination riddled with needless SPA bullshit, but the old reddit design was pretty clean and minimal and yet an SPA.)
The old Reddit design isn't really an SPA. It's just server rendered with a bit of Ajax for interactivity
Re: You probably don't need a single-page app
#123I'm more interested in the future of "you probably don't need a native app" . It feels like browsers are closing the gap pretty well with things like IndexedDB, offline features, WASM, etc. Still a ways off, but seems like it's getting there. I do worry, though, that it's not really in Apple's or Google's best interest to move that along.
Native will always be the best solution... Because it's native.
Native is only a trade-off that has great performance at other expenses.
Re: You probably don't need a single-page app
#124Earlier quoted context omitted.
React requires too much incantations, rituals and ceremony. You have props and state, context, error boundaries, refs, keys, you have to figure out where state should live, etc. You make a component that contains state. Then you want to use it in a component hierarchy -- now the component is supposed to have props not state. You make a component that has props, now you want to use it at the top level -- now the compo…
You don't have to deal with any of that crap when you deal with react. Just write pure functions as components. The arguments are the props.
Re: You probably don't need a single-page app
#125Totally agree with the article, the spa hype has produced a lot of crappy slow web sites and crippled productivity of many teams for years. I think ppl in the industry are way too young and have the bad attitude to nod add tools in their belt but keep only the last one that has hype. Spa are like applet or Silverlight, just different tech, same goes for ws* vs rest api and so on...
The current culture is to only keep a job for ~2 years before moving on, why wouldn't they adopt that attitude?
Re: You probably don't need a single-page app
#126I'm more interested in the future of "you probably don't need a native app" . It feels like browsers are closing the gap pretty well with things like IndexedDB, offline features, WASM, etc. Still a ways off, but seems like it's getting there. I do worry, though, that it's not really in Apple's or Google's best interest to move that along.
I mean, it's neat and all, but most websites aren't CPU-bound.
Re: You probably don't need a single-page app
#127Server-Side rendering tightly couples your front-end to your application server. Scaling the site means scaling up that application server. A bug in one "page" of the app can cause the whole application server to go down.
If you leverage client-side rendering then it's easier to decouple your front-end from the back meaning you can take advantages of things like segregated micro/serverless services and progressive web apps. You can also re-use those services for multiple applications, making it easier to keep the business logic OUT of your pages and in an API layer where they belong.
I agree that SPAs are not the solution for everything, but I think that server-side rendering is on it's way out.
Re: You probably don't need a single-page app
#128Earlier quoted context omitted.
> What's the difference between polyfill or some framework, and something like Qt or SDL? As a user, I usually can't even tell when they're using a polyfill on the web (except when they stop, like GitHub did with type=date). (As a developer, I often can't tell the difference, either. Some of them are that good!) So long as you generate HTML/CSS/JS, it doesn't matter to me how you do it. That's as 'native' to the web…
> I can spot Qt a mile away. A lot of the visuals look wrong and a lot of the controls don't behave right. You mean it has no respect for your native toolkit... just like the web?
Re: You probably don't need a single-page app
#129I'm more interested in the future of "you probably don't need a native app" . It feels like browsers are closing the gap pretty well with things like IndexedDB, offline features, WASM, etc. Still a ways off, but seems like it's getting there. I do worry, though, that it's not really in Apple's or Google's best interest to move that along.
It's in Googles interest as everything they deliver is through the browser. Not so much for Apple or Microsoft though. Personally I will be quite sad if I end up loosing so much control over my computing environment.
Re: You probably don't need a single-page app
#130Coming from similar background as author (various legacy web apps with all the challenges of learning now useless js frameworks) - I’m now have a different opinion: SPA approach should be the default unless you have specific requirements to add html SSR (and even then google is pretty good at indexing public spa content too). So, respectfully disagree.