Live data from Hacker News

None of my projects want to be SPAs

whatisjasongoldstein.com

51–60 of 362 posts

Re: None of my projects want to be SPAs

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

Re: None of my projects want to be SPAs

#52
post #47

Earlier quoted context omitted.

jQuery 2.1.3 is 27.8Kb. React + React DOM is 35.6Kb. 7.9Kb extra isn't nothing, but it's not something many sites really need to stress over. It's definitely not enough to state using React is adding "large amounts of framework bloat".

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.

If you have 2mb of "react bloat" you wouldn't have "a dozen lines of jquery".

Re: None of my projects want to be SPAs

#53
post #47

Earlier quoted context omitted.

jQuery 2.1.3 is 27.8Kb. React + React DOM is 35.6Kb. 7.9Kb extra isn't nothing, but it's not something many sites really need to stress over. It's definitely not enough to state using React is adding "large amounts of framework bloat".

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.

2mb is a LOT of code, like an absurd amount for most projects. That almost always points to larger issues, like a complete disregard for bundle size in the first place.

And if the project isn't worrying about bundle size at all, then even their vanilla/jquery page is going to end up bloating a ton as well.

More often than not the culprit in 2mb bundle sizes is a a few packages that include "data" in the bundle (For example, i've seen timezone and locale information bloat bundles by megabytes, and in one case a 5mb bundle ended up being 4.6mb of zip codes...)

Re: None of my projects want to be SPAs

#54

I went from MVC style all-in-one frameworks (Rails, Laravel) to application APIs fronted by single page applications and hope the developer mindshare tilts back to MVC frameworks. Something that'd take me an hour or two in Rails can take a week using these new tools, even after being reasonably experienced with them. Don't even get me started on Apollo (not my thing at all, and from my experience most don't know how…

For a component here and there React is a pretty bad choice because of its size. Svelte could be a more suitable option, but I’m not so sure it passes the magpie test.

Re: None of my projects want to be SPAs

#55
post #28

Personally I was dumbfounded by complexity of doing async things in redux. Libraries like redux-thunk, redux-sage, redux-observable should not exist. The amount of boilerplate required was incredible and meaningful typescript support was very difficult to achieve. Then I tried mobx, I was able to write a small app after 15 minutes of reading the docs and now I love react.

My experience as well, MobX saved React for me, and I did a 180 from hating it to loving it.

Re: None of my projects want to be SPAs

#56
We recently went in the opposite direction for a student project I'm working. We have a full SPA Angular frontend, and we use CouchDB as our datastore. There is a Node "backend," but it only serves things like Slack integration, the browser has a local PouchDB instance that directly syncs with the server's CouchDB. This way, we can deploy hotspots with nothing more than a Couch install and a static server for the SPA.

The modern, offline web is great. If we had to do this in a native app we would never have gotten the project off the ground, because we initially need to use BYOD phones which were evenly split from iOS/Android. We'd have had to use three languages, but a Mac, get developer licenses, and learn Swift and Java just to get an offline frontend, and sharing business logic code would be impossible.

Re: None of my projects want to be SPAs

#58
post #47

Earlier quoted context omitted.

jQuery 2.1.3 is 27.8Kb. React + React DOM is 35.6Kb. 7.9Kb extra isn't nothing, but it's not something many sites really need to stress over. It's definitely not enough to state using React is adding "large amounts of framework bloat".

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 components and composing your app pushes you to write less code. Plus React gets things like code splitting for free with webpack if you use lazy, so the first page load only downloads things that are actually needed to get to interactive.

No doubt some less considerate developers will still manage to write giant apps that take ages to get started, but they don't have to. Bloated apps are a function of developer's choices rather than React (or any other JS framework) forcing the apps to be bloated.

Re: None of my projects want to be SPAs

#60

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.

If you have 2mb of "react bloat" you wouldn't have "a dozen lines of jquery".

[deleted]
Post reply on HN