Live data from Hacker News

Single Page Application Is Not a Silver Bullet

blog.bloomca.me

101–110 of 111 posts

Re: Single Page Application Is Not a Silver Bullet

#101

I always thought the decision was: - Content site = NOT single-page-app - Application = single-page-app Maybe there's more of a gray area between content sites and applications these days, but I think it's still pretty obvious: If most of the user's time is spent reading content, it's a content site.

I work in ecommerce and I feel it’s somewhere in between. We need to build for seo optimizations for the category/product experiences yet there is a lot of application like intersections, especially on the category filtering and the product sku selections. Quickshops, In store pickup modals, user specific recommendations trays, add and edit reviews et all. Different caching for server render at the edge vs personaliz…

Is it really worth the trade-off? I remember eCommerce sites trying to do similar levels of interactivity with Flash too. I just think, for a catalog site, it seems like you're trying to swim upstream. Especially on mobile.

Re: Single Page Application Is Not a Silver Bullet

#102

Some of the arguments the author mentions are not really good arguments. Basically it boils down to how much you care about the user experience. I designed and developed a SPA for a large real-estate portal in - Initial request is rendered server-side, so TTI is extremely low. Even if the JS hasn't kicked in, the website is already usable. - Back button works perfectly fine. We use the HTML5 `history.pushState` metho…

Do you mind telling which stack you're using?

React 16, Redux, Webpack, a custom router. All transpiled using Babel. On the back-end we also use Python/Django. Nothing out of the ordinary :)

Re: Single Page Application Is Not a Silver Bullet

#103
post #67

We built one of our products as an SPA ( https://usebx.com/app ). I have to say it was a fairly enjoyable experience, and our users like it too (they often add it to their home screen and comment that it feels totally native). The only annoying thing was ios Safari, which has it's own little quirks in certain areas (but those are not limited to just SPAs but any kind of website).

That's a very cool app. I gave it a try when you first posted it on HN and now I'm a regular user! I find it much better than similar native apps, especially because of the offline mode (most invoicing apps seem to lack this). Anyway, thank you for the free tier - works a treat for my needs!

You're welcome, glad you like the app :)

Re: Single Page Application Is Not a Silver Bullet

#104
post #84

Earlier quoted context omitted.

I really don't understand where you're coming from. SPA routing is a solved problem. There are countless modern solutions that are not only trivial to use but offer bonus functionality over traditional approaches, such as isomorphic routing or controlling the state of individual components and elements with routes instead of entire pages. > Should a popup dialog be reflected in the URL state? Should a confirmation pr…

Terms like "solved problem" and "modern solutions" set off my BS detector. Doesn't the existence of countless solutions, rather than relying on built-in browser behavior, imply that it's not a solved problem? No doubt single-page apps have their benefits, but there's an awful lot of new hotness kool-aid being passed around. The JS ecosystem is still suffering heavily from the inner platform effect.

> Doesn't the existence of countless solutions … imply that it's not a solved problem?

Is this a serious question?

It seems like you're letting a bit of bias against the JS ecosystem invade your thought process here. There are countless solutions because they range from generic, such as a simple routing helper, to deeply integrated, such as react-router.

> rather than relying on built-in browser behavior

You mean the built-in behavior of navigating away from the current page? The single page application?

Re: Single Page Application Is Not a Silver Bullet

#105

I always thought the decision was: - Content site = NOT single-page-app - Application = single-page-app Maybe there's more of a gray area between content sites and applications these days, but I think it's still pretty obvious: If most of the user's time is spent reading content, it's a content site.

> I always thought

and you were right, although, with things like Angular Universal and initial server side rendering of SPAs in general, are changing this.

Re: Single Page Application Is Not a Silver Bullet

#106
post #84

Earlier quoted context omitted.

Sure there’s something to reimplement. Ensuring that changes to the view state are represented in the URL bar isn’t trivial. Should a popup dialog be reflected in the URL state? Should a confirmation prompt? What about browsing a hierarchy of menus? With web pages as documents that only use JavaScript to “decorate” things, you get this for free. And it’s likely aligned with what users expect.

I really don't understand where you're coming from. SPA routing is a solved problem. There are countless modern solutions that are not only trivial to use but offer bonus functionality over traditional approaches, such as isomorphic routing or controlling the state of individual components and elements with routes instead of entire pages. > Should a popup dialog be reflected in the URL state? Should a confirmation pr…

> SPA routing is a solved problem.

Is it? I'm new to web development, so I don't understand your statement. E.g. does any SPA framework offer support to the stop button? I've been learning Vue and Mithril recently. Apparently, both libraries/frameworks have no support for the stop button, so you cannot use the browser's stop button to cancel routing/loading stuffs after you clicked on a link.

Re: Single Page Application Is Not a Silver Bullet

#107
post #84

Earlier quoted context omitted.

Sure there’s something to reimplement. Ensuring that changes to the view state are represented in the URL bar isn’t trivial. Should a popup dialog be reflected in the URL state? Should a confirmation prompt? What about browsing a hierarchy of menus? With web pages as documents that only use JavaScript to “decorate” things, you get this for free. And it’s likely aligned with what users expect.

I really don't understand where you're coming from. SPA routing is a solved problem. There are countless modern solutions that are not only trivial to use but offer bonus functionality over traditional approaches, such as isomorphic routing or controlling the state of individual components and elements with routes instead of entire pages. > Should a popup dialog be reflected in the URL state? Should a confirmation pr…

JS devs happily call it a "solved problem" after they completely reinvent it after every release of their framework du-jour. It's solved until it's not, then you solve it again.

Is react-router stable yet? I looked at react a year ago and every tutorial out there used outdated syntax because they revamped the whole thing. The last angular project I worked on tried 3 different approaches through the life of the project.

The point is, with web pages as just documents that come to the browser fully-formed, there's no need to ask the question any more: the URL is the path to the document, and you get a new URL when you get a new document. There's no need to make special cases for popups/etc since the answer is always "no". You just don't do routing logic on the client at all.

Edit: just to be clear about what I'm advocating, if you embrace the document-style non-single-page model, you simply don't worry about view state or how it's routed/represented: any javascript code you do write (jquery etc) doesn't need to touch it, and any "real" hyperlinks that load a new page from the server naturally affect the view state normally.

Re: Single Page Application Is Not a Silver Bullet

#108
post #97

Earlier quoted context omitted.

I think the react dev team is currently working on an official async loading pattern for a future update. But currently webpack, rollup, etc. offer dynamic import, code-splitting, tree-shaking

Not sure if that's what you mean, but when Andrew Clark keeps mentioning the "async" word, he means async rendering, not async loading.

What is an unsolved async loading problem in React you are experiencing?

Re: Single Page Application Is Not a Silver Bullet

#109
post #97

Earlier quoted context omitted.

Not sure if that's what you mean, but when Andrew Clark keeps mentioning the "async" word, he means async rendering, not async loading.

What is an unsolved async loading problem in React you are experiencing?

I don't have any issues with async loading. I'm just saying that I believe what you are referring to when you say the React team is working on an official async pattern is not actually async loading, but async rendering.

At least every time one of their members said the word async in the last couple of weeks/months, it's what they referred to, and it's a completely different (and unrelated) thing. I can't read your mind though, so I'm just guessing.

Post reply on HN