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

61–70 of 362 posts

Re: None of my projects want to be SPAs

#61

Post by seba_dos1 »

masklinn wrote: post #50
arcticwombat wrote: post #45

Earlier quoted context omitted.

SPA isn't automatically the best solution for a page or site with frequent updates. The updates are handled by JavaScript and http calls. You can write a lot of that stuff in a dozen lines of JQuery with nicely refreshing content and ajax instead of throwing in large amounts of framework bloat.

> You can write a lot of that stuff in a dozen lines of JQuery with nicely refreshing content and ajax instead of throwing in large amounts of framework bloat. OTOH jquery is much bigger than you'd expect, there isn't much of a difference between a minimized jquery and vue, or even react once you factored in gzip. And while I've no experience doing so using vue, writing small dynamic react components embedded in larg…

It's 2019, most of the stuff that jQuery used to handle is now included in the browser API. For instance, to have "AJAX", simply try window.fetch instead of $.get.

Re: None of my projects want to be SPAs

#62

Post by pier25 »

After working exclusively on SPAs for a number of years (React, Vue, Inferno) I'm getting out of that unless there is a strong argument in favor such as a hybrid mobile app (and that will go away once we move into Flutter).

I don't want to go back to Rails/PHP/Python though. I like having a REST/GraphQL API. With Hasura I don't have to worry about backend anymore for 80% of the cases.

What I'm doing right now for the front end is using Jekyll with Vue. It's really liberating not having to worry about a router or managing application state anymore. For certain in-house projects I don't even have to use Babel or Webpack anymore and still get to use Async/Await.

Re: None of my projects want to be SPAs

#63

Post by spricket »

I've found the most annoying aspect of using a SPA is having to consume your own API's. Using Swagger or gRPC on both ends helps immensely.

These, combined with Angular CLI or Create React App, allow me to be just as productive as the pre-spa days

Re: None of my projects want to be SPAs

#65

Post by cle »

koblas wrote: post #42
taeric wrote: post #22

Earlier quoted context omitted.

This builds an implication that spa tooling is the way to avoid a mess. Which is ironic to me. As soon as the teams I've seen start piling a ton of extra stuff into the UI, be it types to make things more safe or logic to make things feel faster, you get a mess. Note I'm not claiming either of those are the problem. More code is just almost always more mess. Keep it small. If possible, keep it separate.

There are two forms of mess in my experience, none of them have to do with SPA. 1) You have the problems that different developers have different styles. So when you jump from one area to another in the code base you're hit with WFT this is functional/procedural/inheritiance/composition, etc. style and your first thought is "barf" they did it wrong... 2) People either have huge functions that are spaghetti or tiny li…

These could also partially be language and tooling issues.

There are some languages that are so “powerful”, “flexible”, and unopinionated that every developer has dramatically different coding styles (JavaScript, Scala, etc.). On the other end of the spectrum are tightly prescriptive, constrained languages where everyone’s code looks the same (Go comes to mind).

No doubt team culture plays a part as well, but in team settings it is important to pick tools that are designed for team settings. These tend to prioritize regularity, lack of flexibility, syntactic simplicity, static analysis, etc.

Re: None of my projects want to be SPAs

#66

Post by everdev »

shusson wrote: post #39

If anyone would like an example of the silliness that exists in SPA bundling see https://github.com/angular/angular-cli/issues/6137

> For those of you who use moment-timezone there is a trick to reduce the size (if you can get away with 2012-2022 dates)

Lol, a 3 year solution. I immediately feel sorry for the future devs jumping into a codebase like that on New Year's 2023 trying to figure out what broke overnight.

Re: None of my projects want to be SPAs

#67

Post by seba_dos1 »

shusson wrote: post #25
dictum wrote: post #20

Earlier quoted context omitted.

Until you open some link in the app in a new tab, and a whole new ship must be built before it sets sail.

Usually(hopefully) the initial bundle is cached, so network shouldn't be a problem... still have to initialise the SPA though.

...which still can take significant amounts of CPU and RAM, especially on busy and underpowered hardware that webdevs don't tend to test their apps on.

Re: None of my projects want to be SPAs

#68

Post by braindouche »

Klathmon wrote: post #53
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.

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

Yeah, that was me, sorry. I wasn't given a choice.

Re: None of my projects want to be SPAs

#69

Post by Klathmon »

braindouche wrote: post #68
Klathmon wrote: post #53

Earlier quoted context omitted.

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

Yeah, that was me, sorry. I wasn't given a choice.

lol I did it too once! We were making a PoC one time for a small app, and ended up needing a way to quickly determine some location information related to the zip. I remembered that I saw the ~5mb bundle once that had all the zipcodes in it, and found a library that would let me do that, and bundled it right in.

The PoC ended up working out, and we built the infra to correctly handle the lookups without needing to bundle the entire country from there, but man did that raise some eyebrows from a few other devs that noticed it!

Re: None of my projects want to be SPAs

#70

Post by kadendogthing »

laszlokorte wrote: post #24

What I did for a mobile web app I built last year after the react prototype was to slow on old devices: - Render all pages/routes/states into a single html file (size ~2mb) but each page/component/state hidden via style=display:none;. - then write some hand crafted js (few hundred lines) to add event listeners to forms and show/hide the components depending on url change - cache everything via appcache/serviceworker…

> built last year after the react prototype was to slow on old devices:

Do you have a public implementation available for review? I'm having trouble understanding why this would be the case (I am pretty familiar with React's implementation).

>Render all pages/routes/states into a single html file (size ~2mb)

That's not good at all for mobile web pages.

Post reply on HN