Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You probably don't need a single-page app

journal.plausible.io

Post reply on HN
Print view View original

41–50 of 522 posts

Re: You probably don't need a single-page app

#41

Post by adtac »

hskaw wrote: post #4
ttty wrote: post #2

Normally you'll always need to add something interactive, therefore js. To do that with server side rendering you'll couple the client side to the server side. For example the server has to send a tag with a class name that the client also is aware of that. Therefore you have 1 component, where half is on server side and half of on client side, which in my opinion is not maintainable.

This is unrelated to the article. Many webpages, like HN, use JS but are not SPAs.

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.)

Re: You probably don't need a single-page app

#42

Post by simple_phrases »

tonyedgecombe wrote: post #33
tyingq wrote: post #8

I'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.

Native apps allow Google to collect much more information than they can via the browser. They also allow for a wider range of advertising opportunities.

Re: You probably don't need a single-page app

#43

Post by jtdev »

tyingq wrote: post #35
tonyedgecombe wrote: post #33

Earlier quoted context omitted.

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.

Well it would cut into revenue from the PlayStore. I suppose it's plausible that keeping people in the browser is a good enough trade-off for Google.

I can’t imagine that the Google Play Store is a huge revenue generator, relatively speaking of course.

Re: You probably don't need a single-page app

#44

Post by alexandernst »

save_ferris wrote: post #29
alexandernst wrote: post #21

The main problem with SSR is that the moment you want to do something a little bit outside of the-happy-path of your framework o choice, you're knee deep into sh . Let me give you the simplest possible example. A form with multi-dependant inputs: you select an option from a dropdown, and depending of the choice you made, you see another dropdown with some options, or maybe an entire new set of inputs. Maybe there is…

This is where the hybrid approach they mention in the article really shines. Embed front end frameworks where you need it, and stick to SSR where you don't. It doesn't have to be a binary choice.

Yes, that's what I said in my comment. But if you choose that path, you automatically have to deal with the problems from both worlds. "How do I configure webpack?", "Why is babel not working?", "How do I do _this_ or _that_ in React or Vue or whatever?". Going the hybrid approach is choosing to deal with the problems from both worlds.

Re: You probably don't need a single-page app

#46

Post by nlh »

fxfan wrote: post #6

I need a quick primer on how spa does seo? Do they "server-render" the individual instances of pages too?

Not by default. The big frameworks are first and foremost client side frameworks, which means in an extreme case the server is just sending down (basically), and the client framework handles all of the rendering/data fetching.

BUT — with a bit of work, you can set things up to do server side rendering. It requires you use Node at some point in your server stack, and you essentially call the library (on the server) and run their RenderToString function (each has a slightly different implementation).

There are frameworks for this (next.js, nuxt.js) or you can roll your own - it’s not terribly complicated.

Re: You probably don't need a single-page app

#47

Post by petilon »

I couldn't disagree with this article more. Developing SPAs is easier than server-render applications. The problem is React, Redux, and other such libs make this more complicated than necessary. React is all about surgically making the smallest possible change in the DOM to refresh the page. But is that really needed? Most of the time it is not. Why not re-render the whole page? This is what happens in the case of server-render applications any way, right? Turns out 99% of the time it is performant for the SPA to rerender the whole page. Instead of Angular and React, if you use simple libraries such as UIBuilder ( https://github.com/wisercoder/uibuilder ) and MVC router ( https://github.com/Rajeev-K/mvc-router/ ) you can build simpler applications that work well and are super easy to develop and maintain. Each of those libs is less than 500 lines, so super easy to learn and use.

This article says traditional web servers are stateless, but in the case of SPAs servers are stateful. The opposite is true. Traditional web servers have session state, but in the case of SPAs the servers can be stateless because all servers are responsible for is persistence and query/search.

This article says maintaining browser history is a mess in SPAs. Not true. The same MVC architecture that works so well on the server can be done just as easily on the client, see this lib: https://github.com/Rajeev-K/mvc-router/

This article says server-rendering has fewer more mature tools. That may be true. There are so many new tools for SPAs. But you can ignore them and build SPAs trivially using the libs mentioned above.

This article says server-rendering is better for SEO. Not true anymore. Google and Bing crawlers now execute javascript to crawl your content. This is more work for Google and Bing but not more work for you.

If you know how to do it SPAs are the easiest and best approach because all the server needs to do is implement persistence and query/search using a REST API. If you later need a native mobile client this approach is already more compatible with mobile than if the server renders HTML in addition to persistence and query/search.

Re: You probably don't need a single-page app

#48

Post by robin_reala »

caseymarquis wrote: post #34

For new development, I reach for SPA tools (like VueJS with Webpack) fairly quickly. The reasons for this are: 1. Reusable web components. 2. Clear separation of backend and frontend logic. 3. Using the latest version of javascript. I really like HTML/CSS/JS as tools for building GUIs, but I feel HTML/CSS specifically suffer from the inability to make components. I think there are definitely instances where there is…

If you want to stick to JS, then Node + Express is a fine stack. You can always use React to add functionality to specific parts of the site if you find you need to later.

Re: You probably don't need a single-page app

#49

Post by AnIdiotOnTheNet »

tyingq wrote: post #40
AnIdiotOnTheNet wrote: post #36

Earlier quoted context omitted.

How's that working out when there's more than one browser you have to account for? What's the difference between polyfill or some framework, and something like Qt or SDL? Or I suppose we could just all use chromium, but we could also just all use Windows.

I have to write it for the web already. Writing a native Android and a native iOS app is additive if the web version is "good enough". There's no scenario where I only have to write two native apps. Perhaps there is for other people.

Consider that maybe there are uses for software where the web isn't necessary and isn't even the first choice.

You're a hammer, so everything is a nail. The reality is that the web is a horrible choice for a whole lot of things. It's a document platform with parts of an application platform shoe-horned in and bolted on, and the result looks like a garbage fire to people who come from the land of native software.

Re: You probably don't need a single-page app

#50

Post by tyingq »

jtdev wrote: post #43
tyingq wrote: post #35

Earlier quoted context omitted.

Well it would cut into revenue from the PlayStore. I suppose it's plausible that keeping people in the browser is a good enough trade-off for Google.

I can’t imagine that the Google Play Store is a huge revenue generator, relatively speaking of course.

$24.8 billion in 2018[1].

[1]https://www.statista.com/statistics/444476/google-play-annua...

Post reply on HN