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

61–70 of 522 posts

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

#61

Post by caseymarquis »

danielovichdk wrote: post #28

I tried the other day, yet again, to give it a go. You know, firing up VS Code and make an app with express, node, react bla bla bla. Coming from the .NET toolchain and expecting a lightweight, easy to start with approach I was yet again totally shocked. The hundreds of possible directions you can go in, in terms of frameworks, packages and what not is ludacris. I stopped working when my node modules directory topped…

I pretty exclusively use .NET backends with VueJS frontends. You get all the power of the MS devtools for the backend, near total separation of backend and frontend logic, and then you get all the SPA benefits in the frontend. I absolutely love using SPA tools for frontend development (you just have to spend a year or so with them and really get comfortable, so maybe it's stockholm syndrome), but I can't imagine switching to a dynamic language for backend development.

I may switch things up once WASM is further along. I would love to be using C# on both sides. I would still want very clear backend/frontend separation though.

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

#62

Post by elizabeth_olu »

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.

https://www.elizabethblog.com.ng/2019/02/two-people-were-kil...

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

#63

Post by mattferderer »

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…

Once you know how to use the tools (Webpack with Hot Module Reloading, React/Vue/Whatever, Storybook, TypeScript), it is hard to work without them.

They offer a ton of advantages, especially speed of development if you have a clear separation of frontend & backend logic. If you can mock your backend & develop the front end all by itself without any other code needed, you can go at crazy fast speed. You are also able to focus on UX/UI without needing to think at all about the backend. I feel there is a ton of value in this, whether or not your app is a SPA or not.

I think tools like Gatsby will make building actual SPAs easier down the road. They offer huge speed advantages the longer someone is on the site. Though one could gain a lot of these with just preloading content & HTTP/2 as well. As the article said "It all comes down to tradeoffs". I would also argue what resources you have available & the value of speed on your site.

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

#64

Post by cc81 »

danielovichdk wrote: post #28

I tried the other day, yet again, to give it a go. You know, firing up VS Code and make an app with express, node, react bla bla bla. Coming from the .NET toolchain and expecting a lightweight, easy to start with approach I was yet again totally shocked. The hundreds of possible directions you can go in, in terms of frameworks, packages and what not is ludacris. I stopped working when my node modules directory topped…

.NET is not that simple either, you are just used to it. Beginners will think it is confusing with .NET, .NET Core, .NET standard for example.

There are many options in the front end sure but when you just pick something and learn it then it is not very difficult to get started.

Just start with for example just React or Vue and don't add any state management. Create the apps with their CLI and follow the tutorials on their homepages.

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

#65

Post by subpixel »

On the one hand, site like https://dev.to/ that are built in Rails and rival the speed and performance of any _static site_ support the argument that you can just use the tools you know.

On the other hand, to get your Rails site to function that well takes a lot of work - it is by no means the starting point.

Systems like Next.js and Gatsby.js and others are attractive in that A) they offer the ability to use both server-rendered and client-rendered React, and B) exceptional performance is the starting point. It's up to you to slow it down, not speed it up.

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

#66

Post by petilon »

s_y_n_t_a_x wrote: post #59
petilon wrote: post #47

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 se…

You don't need React, Redux, and other such libs, true. But you're missing the point of them. It's to prevent the problems that cropped up after years of jQuery development. Too many side-effects and poor state management lead to very hard to find bugs. When you follow the redux (or whatever state lib) flow you prevent a lot of these issues.

React, Redux and other such libs solve the problem while overcomplicating the programming model. My point is that 99% of applications don't need the complexity introduced by surgically making the smallest possible change in the DOM to refresh the page. There are simpler libs out there that eliminate 99% of the complexity of React, Redux etc while providing 99% of the benefits.

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

#67

Post by kyledrake »

Agree with the article. I find server views to be substantially easier to work with.

But more importantly, I also find server view rendering to be a faster, better UI experience. It's really frustrating having to wait several seconds for a SPA to load, or to have unexpected behavior when clicking the browser back button, or failing completely because some random hunk of JS garbage errored out, and it's one of the big contributors to why I don't really like using Facebook or Twitter anymore. They murder my browser with megabytes worth of slow SPA crap to give me less than a few kilobytes of meaningful data (and/or people screaming at each other). Gmail now takes 10-20 seconds for me to load at this point, on my high end laptop. I just want to switch to HTML mode by default.

I definitely get edge cases like Slack, but honestly don't think SPA has been a positive development, overall. I think the web was better as a document/HTML oriented design.

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

#68

Post by save_ferris »

alexandernst wrote: post #44
save_ferris wrote: post #29

Earlier quoted context omitted.

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.

But configuring webpack is usually just an initial set-up cost. I've never had to go back and rejigger webpack once it's set up. You might have to touch it again if you make major changes to how you serve assets or something, but these one-time costs are part of development.

> Going the hybrid approach is choosing to deal with the problems from both worlds.

This is true of any technology. Every framework, language, library, etc. comes with a cost in setup, design, maintenance, etc. For us, the cost of dealing with problems from both worlds is much, much lower than trying to shoehorn a SSR app with SPA-like functionality. By limiting the size and scope of the SPA, you avoid a lot of the really hairy state management problems that can arise when an SPA is trying to keep track of too much state.

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

#69

Post by mduerksen »

To add some use cases where an SPA would be the favorable choice:

- Web-tech front-end for an embedded device. The device, which often has very limited CPU cycles, is not burdened by rendering.

- Apps that are intended to be running locally and on multiple platforms (e.g. via Electron), as well as in browser.

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

#70

Post by tyingq »

AnIdiotOnTheNet wrote: post #49
tyingq wrote: post #40

Earlier quoted context omitted.

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.

I'm not sure I understand why browsers getting closer to native apps ruins anything for anyone else. You're still able to hammer your nails however you want.
Post reply on HN