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…
Single Page Application Is Not a Silver Bullet
101–110 of 111 posts
Re: Single Page Application Is Not a Silver Bullet
#102Some 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?
Re: Single Page Application Is Not a Silver Bullet
#103We 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!
Re: Single Page Application Is Not a Silver Bullet
#104Earlier 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.
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
#105I 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.
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
#106Earlier 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…
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
#107Earlier 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…
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
#108Earlier 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.
Re: Single Page Application Is Not a Silver Bullet
#109Earlier 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?
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.
Re: Single Page Application Is Not a Silver Bullet
#110SQL Server has had check constraints since at least the year 1996.