Live data from Hacker News

You probably don't need a single-page app

journal.plausible.io

71–80 of 522 posts

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

#71
post #66

Earlier quoted context omitted.

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.

You don't get much simpler than Redux.

And React by itself is very simple, you don't even have to use JSX. It's a great templating library, with great documentation and a huge community.

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

#72

Or microservices. Or nosql. Or containers. Or graphql. Free tech is not zero cost tech. Size your stacks to your actual needs.

I happened to watch a conference talk on YouTube by the director of infrastructure at Netflix. He closed it out by saying, yes we open source everything, and yes this solution works for us. But just because we do it doesn't mean you should. Do what works for you.

But in reality...I only need it because people on the other side of the interview table expects every engineer to have 3-5 years experience of x,y, z.

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

#73

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…

I don’t think this is about edge cases but SPA have been abused. Imagine using google docs as a server rendered experience. Or any of the apps in iCloud.com. There are use cases where it makes sense and use cases where it doesn’t.

Most of your complaints are about poor implementation but if a large percentage of people poorly implement SPA then it still looks bad. I used to say you could make a very native experience with a hybrid web app for mobile. While this is absolutely true, most people don’t pull it off so I get the critism.

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

#74
post #23

Earlier quoted context omitted.

> Normally you'll always need to add something interactive Especially in news, articles, longreads, right? /s Most of the internet content would be perfectly fine without interaction, or with ordinary, oldschool POST forms

News web site can return part of the page (e.g. news article) to decrease TTFB, and then load less important content (e.g. news recommendation) after. As author said, it is tradeoff.

... or inline all in one html on server side and send it down at once?

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

#75

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

I think dev.to is an SPA. But not built with a framework.

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

#76
post #66

Earlier quoted context omitted.

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.

You don't get much simpler than Redux. And React by itself is very simple, you don't even have to use JSX. It's a great templating library, with great documentation and a huge community.

>You don't get much simpler than Redux.

Not true. With Redux you write reams of actions and reducers and other such unnecessary crap in the name of state management, when in fact most client apps don't have state, all they do is fetch data from the server, display it, send updates back to the server.

React used to be a simple lib, now it is getting more and more complicated. Look at the libs I mentioned they are way simpler.

>you don't even have to use JSX

But JSX is the good part of React. You get compile-time checking of your expressions if you use TypeScript and you get syntax coloring, intellisense etc for both HTML and JavaScript.

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

#77

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…

> Coming from the .NET toolchain and expecting a lightweight, easy to start with approach I was yet again totally shocked.

> I stopped working when my node modules directory topped 60mb and I still hadn't made a data layer.

This is cute.

I have a 40gb virtual machine with Windows + VS Enterprise and SQL Server, that I have to use to work on a single .NET project that can't be migrated to .NET Core yet.

What is 60mb compared to that?

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

#78
post #7

Earlier quoted context omitted.

> The message is build with what accomplishes your goals and works with your team's skills. Unfortunately most teams cannot be trusted to pick the right tool for each job without overcomplicating the planned implementation. Ego and the yearning to do “cool stuff” conspire to derail projects that could have been built without fuss using simpler tools.

>Unfortunately most teams cannot be trusted to pick the right tool for each job without overcomplicating the planned implementation. Ego and the yearning to do “cool stuff” conspire to derail projects that could have been built without fuss using simpler tools. Force them to only use simple tools and the good ones will move elsewhere because they know that being stuck on just the simple things is going to limit their…

Good riddance! A project is undertaken to achieve some specified result, not to advance a career or learn some new tool. Don’t get me wrong: those lofty things are welcome when they occur as a byproduct of developing commercial software, but these cannot be the driving factor behind decisions that affect the bottom line.

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

#79

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…

With gmail: Move your mouse pointer down to the lower right corner of the tab. Do a forced refresh (Ctrl+f5) and you'll see some text pop up while it's loading, one of which is a link to a basic HTML version of the site. Click on it and you're back to what appears to be almost the original gmail interface. Up the top of the page you'll see an option to make it default.

It's super fast. Almost absurdly so, compared to the "full" gmail experience. Added bonus: It gets out of the damn way so you can just do what you came there to do: write and read email.

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

#80
post #76

Earlier quoted context omitted.

You don't get much simpler than Redux. And React by itself is very simple, you don't even have to use JSX. It's a great templating library, with great documentation and a huge community.

> You don't get much simpler than Redux. Not true. With Redux you write reams of actions and reducers and other such unnecessary crap in the name of state management, when in fact most client apps don't have state, all they do is fetch data from the server, display it, send updates back to the server. React used to be a simple lib, now it is getting more and more complicated. Look at the libs I mentioned they are way…

If you don't need state, don't include it. That's the beauty of React. But as far as a state management lib goes, Redux is one of the simplest, go look at the source.

I agree JSX is very nice. It's one of the best features of React, and another reason React is a great templating lib. My point was you don't need it. React does a lot of other nice things like browser compatibility, event management. If you want a smaller implementation, use preact or some other template lib.

When dealing with React and Redux you are just dealing with functions. You could do everything in pure functions.

Post reply on HN