71–80 of 328 posts
> Even if you need to preserve client state between page loads (for e.g. music or video playback) you can let the browser do most of the heavy lifting by fetch()ing a new page and replacing your content container at the DOM level. Anyone knows of some easy to learn example of such DOM replacement?
Earlier quoted context omitted.
Don't need a SPA for that. Local HTML based documentation was a thing long before SPA was even a term.
How does that work exactly?
Earlier quoted context omitted.
The one that drives me crazy are websites that say they only support safari on iOS... It’s all safari under the hood.
Safari on iOs is a bit special. Some features are missing compared to the Mac version. You also need quite a few safari ios specific code if you want to build a web app. But this is a bit broken since Apple wants you to publish to the appstore and not release web apps anymore. You also need a Mac to debug safari on iOs. I hate Safari.
Earlier quoted context omitted.
The most common reasons for building a SPA: * That is the design pattern dictated by your large framework. * Maintaining state is absurdly simple, but it requires original code if not using a big framework. * The browser provides a simple standard API for interacting with HTML, but your framework provides abstractions you didn’t know you could live without. That’s it. Developers twist themselves in knots trying to qu…
I'll offer up another reason, which I feel is a little more accurate: * Your web app requires heavily interactive bits, such as smart forms, smart tables, previews, content editing, etc. To deliver such functionality in a maintainable way, you use a framework. (As a side note, yes it is possible to deliver this functionality in vanilla JS, but to make it maintainable one must essentially build an ad hoc framework.) B…
Earlier quoted context omitted.
There are very clear reasons for SPAs to exist. 1) Prevent reloading of the page every time the user clicks a link, reducing the overhead of fetching common content between pages multiple times (headers, menus, etc) and providing a more seamless experience to the user. 2) Better emulate the feel of mobile applications, for users who spend most of their time on their phones and don't often or have never interacted wit…
> Prevent reloading of the page every time the user clicks a link, You don't need a SPA for that. And page load/render times are much shorter when html is delivered straight to browser fr most applications > Better emulate the feel of mobile applications, That's pretty weak defense. > Once the browser downloads and caches the bundle on initial load, the user can revisit the page Giving we're now in the world of Conti…
Please don't dilude conversations like this, it doesn't do anyone any favors.
Earlier quoted context omitted.
Don't need a SPA for that. Local HTML based documentation was a thing long before SPA was even a term.
How does that work exactly?
Seems like a list of every web development ideal that gets upvoted on Hacker News. Still, I think the list can pretty much condensed down to one point: Use whatever technology is appropriate for this site or web app. Because a lot of developers seem to have a 'when all you have is a hammer' attitude towards web development. They learn React/Vue/Angular/whatever, then seemingly decide everything they will ever build w…
> Your documentation doesn't need to be an SPA. Disagree with this. Having the entire documentation site working as normal on my browser when I have bad/no internet connectivity is extremely useful.
Earlier quoted context omitted.
How does that work exactly?
It's literally just a folder full of perfectly normal HTML files. You don't need Javascript or a SPA to double-click one of those and look at it in a browser. Even better, if your operating system has full-text file indexing, it'll be able to search them normally.
This sounded more like a anti-SPA post. Maybe the title should be "Reasons for not building a SPA".
The most common reasons for building a SPA: * That is the design pattern dictated by your large framework. * Maintaining state is absurdly simple, but it requires original code if not using a big framework. * The browser provides a simple standard API for interacting with HTML, but your framework provides abstractions you didn’t know you could live without. That’s it. Developers twist themselves in knots trying to qu…