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

None of my projects want to be SPAs

whatisjasongoldstein.com

Post reply on HN
Print view View original

131–140 of 362 posts

Re: None of my projects want to be SPAs

#131

Post by s_y_n_t_a_x »

kerkeslager wrote: post #115
WrtCdEvrydy wrote: post #102

Earlier quoted context omitted.

Server side rendering mounts your application in the server and sends down html along with an initial state. The client receives this initial state and uses it with the html to glue together a working UI on the client. This removes the massive JS bloat into raw html and split JS for each component. Instead of sending 3MB of JS, you send only the JS needed to render the current page... and send additional JS as a user…

Okay, but that's an even worse idea than what I've seen Redux used for. Now you're splitting the UI between client and server in a completely custom way, that adds even more complexity. Worse, the performance is likely to be worse because now you're paying the bulk JS load cost of loading Redux AND the latency cost of loading small parts as you go: the worst of both worlds. I doubt this is what the Redux folks had in…

Redux is tiny. And with HTTP2 it's better to send multiple small resources than one large payload, especially when it's JS which will lock up when parsing.

Re: None of my projects want to be SPAs

#132

Post by zerotolerance »

Illniyar wrote: post #122

Do we really need to defend SPA every other week? The market, users, product, ui/ux designers and the vast majority of developers decided that SPA is a better user experience. Page loads greatly degrade the user experience, especially when you have long lag (which for many of us the reoundabout time is longer then the download time of 100k). Even if you make your site extremely lean, it's still a worse experience, an…

Craigslist and Amazon don't compete?

Re: None of my projects want to be SPAs

#133

Post by palerdot »

kerkeslager wrote: post #79

Back when I was doing React, what pulled me in was that it WASN'T a framework for SPAs. What I got from it was the ability to build UI widgets (components, in React terms) that worked within a page, and were composable with other UI widgets. With that approach, you really wanted to keep every component self-contained. That meant a lot of bookkeeping with passing events back and forth between parent and child widgets,…

Thinking of Redux as a 'detached state tree' that the whole app can subscribe too might give a better picture of some problems that it is solving. In React, when you lift state up and up, you mostly end up tracking lot of irrelevant state in the top most component which kind of weirdly manages lot of state just for their children. There are some genuine use cases of Redux by tracking the whole 'app state' in a detached way, safely update/transform them (with pure functions) and more importantly you could just subscribe for necessary data at any level. Context API is helpful, yes, but Redux (or MObX or any state management tool) is still helpful when done right.

Re: None of my projects want to be SPAs

#134

Post by jermaustin1 »

Illniyar wrote: post #122

Do we really need to defend SPA every other week? The market, users, product, ui/ux designers and the vast majority of developers decided that SPA is a better user experience. Page loads greatly degrade the user experience, especially when you have long lag (which for many of us the reoundabout time is longer then the download time of 100k). Even if you make your site extremely lean, it's still a worse experience, an…

>the same ones who surf the web with js disabled.

I used a lot of applications out there that aren't SPAs, I browse with JS turned on, and I believe that SPAs are nice in certain use cases, but for a large portion of web applications, you are primarily doing simple CRUD work, and don't need an SPA for that.

Re: None of my projects want to be SPAs

#135

Post by s_y_n_t_a_x »

rossdavidh wrote: post #108

This may be a mean thing to say, but basically I think SPA's are massively overused, because developers want to demonstrate that they can do them. Why? Because big companies like Facebook and Google use them. Why? Because they actually are doing things that require them. 99% of the SPAs in production are things that should have been done the old Rails/Django/Laravel way, but that would not set you up as a developer w…

It's really simple, if you're developing a web app, use a SPA stack. If you're developing a web page, use the minimal amount of tech you need on top of HTML, ideally where the HTML functions without JS.

Re: None of my projects want to be SPAs

#136

Post by kingdomcome50 »

kerkeslager wrote: post #79

Back when I was doing React, what pulled me in was that it WASN'T a framework for SPAs. What I got from it was the ability to build UI widgets (components, in React terms) that worked within a page, and were composable with other UI widgets. With that approach, you really wanted to keep every component self-contained. That meant a lot of bookkeeping with passing events back and forth between parent and child widgets,…

I have to let you in on a big secret. State has always been global. Have you ever worked on an application backed by an RDBMS? Redux simply moves state. It doesn’t expose it any more than a database.

Re: None of my projects want to be SPAs

#137

Post by extra88 »

onion2k wrote: post #58
arcticwombat wrote: post #48

Earlier quoted context omitted.

I'm not talking about the bloat of the framework itself but the code you write to use the framework. When you have 2mb worth of "React code" and the framework itself only takes up 35.6kb, that's a lot of bloat.

Having used the internet for 25 years I can confidently say most React apps are far smaller than most jQuery apps, mainly because jQuery apps didn't use compilers or bundlers. Hell, most didn't even use minifiers . Even ignoring that, React app sizes are getting better. Modern React apps (basically since 16.7) that are written with things like Suspense, lazy, and hooks are usually pretty small. Writing functional com…

> Modern React apps (basically since 16.7) that are written with things like Suspense, lazy, and hooks are usually pretty small.

Come on, 16.7 was released in December and 16.8, with stable Hooks, was last week! It's interesting that React has added these features and it bodes well for the future but you can't claim capabilities that have only existed for the a few months is what constitutes "modern." React's pace of adoption has been remarkable but that also means there's a lot of code that already exists that isn't going to be changed right away to take advantage of these features.

Re: None of my projects want to be SPAs

#138

Post by brightball »

sharps_xp wrote: post #51

I don't use Elixir/Phoenix, but Phoenix's LiveViews brings all the butter to the monolith bread. State remains on the server, only visual state is sent over websockets, and the HTML is transformed with morphDOM. https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera... I hope to see this idea brought to Rails, but the its websocket story doesn't seem there yet.

It's a combination of the websocket story and the server side HTML story that make this possible.

HTML rendering with Phoenix is lightning fast. https://www.bignerdranch.com/blog/elixir-and-io-lists-part-2...

Re: None of my projects want to be SPAs

#139

Post by barbecue_sauce »

onion2k wrote: post #58
arcticwombat wrote: post #48

Earlier quoted context omitted.

I'm not talking about the bloat of the framework itself but the code you write to use the framework. When you have 2mb worth of "React code" and the framework itself only takes up 35.6kb, that's a lot of bloat.

Having used the internet for 25 years I can confidently say most React apps are far smaller than most jQuery apps, mainly because jQuery apps didn't use compilers or bundlers. Hell, most didn't even use minifiers . Even ignoring that, React app sizes are getting better. Modern React apps (basically since 16.7) that are written with things like Suspense, lazy, and hooks are usually pretty small. Writing functional com…

> Modern React apps (basically since 16.7)

So like, a month ago?

Re: None of my projects want to be SPAs

#140

Post by repsilat »

s_y_n_t_a_x wrote: post #135
rossdavidh wrote: post #108

This may be a mean thing to say, but basically I think SPA's are massively overused, because developers want to demonstrate that they can do them. Why? Because big companies like Facebook and Google use them. Why? Because they actually are doing things that require them. 99% of the SPAs in production are things that should have been done the old Rails/Django/Laravel way, but that would not set you up as a developer w…

It's really simple, if you're developing a web app, use a SPA stack. If you're developing a web page, use the minimal amount of tech you need on top of HTML, ideally where the HTML functions without JS.

Does that help much? The distinction between "web app" and "web page" seems fuzzier than the question "would a SPA lib/framework be useful here?"

Is Reddit a web app? Is Twitter? Facebook? They all started with server-generated HTML, all kinda feel "document-like", all of them involve scrolling (if that means anything.)

Is the "app" boundary further along the chain, like at Google Docs?

I think instead of trying to come up with definitions to classify things (and probably argue for the meaning of those definitions from the conclusions we want to draw) we should ask,

- Will this help developers?

- Will this make users lives better?

Post reply on HN