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

41–50 of 362 posts

Re: None of my projects want to be SPAs

#41

Post by korm »

lucidone wrote: post #21

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…

I hope we don't go back to MVC for everything. I think we just have to use the right tool for the job. If an app is highly interactive or will have frequent data updates, or if it's supposed to be used almost like a native app, a SPA is the perfect way to achieve this. If it's going to be like most sites, traditional MVC will probably be better.

Not that react isn't great for traditional websites, I've just seen too many fullstack or backend devs struggle with it, so if they're going to be involved in the frontend it may be worth considering the alternatives.

Re: None of my projects want to be SPAs

#42

Post by koblas »

taeric wrote: post #22
koblas wrote: post #15

There are lots of applications which don't really benefit from being an SPA (blogs, books, etc.). As soon as you start thinking about meaningful interactions you quickly start having to pile enough JavaScript into the HTML that you quickly run into a mess - defining ways to marshal data back and forth with an ad-hoc structure. While SPA tooling like React are incomplete since they don't provide all of the client/serv…

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 little functions to avoid complexity that are one line if statements.

Both of these are usually rooted in lack of a shared code culture, these are not SPA issues but team issues.

Re: None of my projects want to be SPAs

#43

Post by arcticwombat »

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…

2mb html file, + whatever else for initial load?

That's only 1-2 seconds on a fast connection.

If you have zero of that content cached locally and are on a mobile or just not-fast connection it'll be way more than 1-2 seconds.

Your "solution" is one of the ones responsible for locking up mobile browsers all over the place, because the browser still has to deal with the entire DOM, and it's often done way inefficiently.

Re: None of my projects want to be SPAs

#44

Post by rpeden »

polote wrote: post #31
asattarmd wrote: post #16

For CRUD apps, using Rails etc. with Turbolinks[1] is the best way to go IMO. It gives you the SPA feel without the headache. In all SPAs, we load JSON, with Turbolinks, we load HTML of that page alone (without the CSS, JS etc). [1] https://github.com/turbolinks/turbolinks

It is the best way to do what ? because from what I understand turbolink is giving you nothing. The only thing you can have is activating a a loaderbar at the top of the page ... Turbolink is a crutch for people that are not able to server side render an html in a few milliseconds.

It's giving you more than nothing.

It's fetching and replacing the HTML that needs to be changed, but removes the need to do a full-page reload, so the browser doesn't have to re-load and re-parse all of the HTML, and JS, and CSS. Even though the browser will keep a lot of this stuff cached, Turbolinks can make a site feel a lot faster from a user's perspective. But regardless, it's more than just a loading bar at the top of the screen.

Whether it's the right fit or not depends a lot on what you're trying to do.

Re: None of my projects want to be SPAs

#45

Post by arcticwombat »

korm wrote: post #41
lucidone wrote: post #21

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…

I hope we don't go back to MVC for everything. I think we just have to use the right tool for the job. If an app is highly interactive or will have frequent data updates, or if it's supposed to be used almost like a native app, a SPA is the perfect way to achieve this. If it's going to be like most sites, traditional MVC will probably be better. Not that react isn't great for traditional websites, I've just seen too…

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.

Re: None of my projects want to be SPAs

#46

Post by iraldir »

arcticwombat wrote: post #35
nisten wrote: post #33

To add to this, bandwidth and app size is not important to the user(they'll watch netflix later). The only thing they notice, is response time. React with well defined static content routing and server-side rendering is amazing at this because the first packets that the server sends the user is html/css jumble. You can get your app to show text and formatting in as little as 20ms(depending on where you deploy it), th…

How is this amazing? We've been "server side rendering" since the inception of the internet. If you build your pages with CSS at the top and JS at the bottom you're already achieving most of that effect right there, no extra tools needed. The browser will load the css and content first, and then process the JS requests (Which are easily cachable by the server AND the browser).

universal web app, that is web apps that can be rendered from the server or on the client are indeed amazing. Blazing fast loading on first use (like a traditional webpage), but also super fast to use for every subsequent actions (like a SPA). For a website like amazon, that can make a huge difference in revenues. The price to pay on the other hand is complexity. It demands programmers that really know what they are doing, and even then, still has an overall cost you wouldn't find with an SPA. Is it worth it? Well if you're a startup with 200 users, probably not. But for a big company, that can be a big way to improve results

Re: None of my projects want to be SPAs

#47

Post by onion2k »

arcticwombat wrote: post #45
korm wrote: post #41

Earlier quoted context omitted.

I hope we don't go back to MVC for everything. I think we just have to use the right tool for the job. If an app is highly interactive or will have frequent data updates, or if it's supposed to be used almost like a native app, a SPA is the perfect way to achieve this. If it's going to be like most sites, traditional MVC will probably be better. Not that react isn't great for traditional websites, I've just seen too…

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.

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

Re: None of my projects want to be SPAs

#48

Post by arcticwombat »

onion2k wrote: post #47
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.

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.

Re: None of my projects want to be SPAs

#49

Post by laszlokorte »

arcticwombat wrote: post #43
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…

2mb html file, + whatever else for initial load? That's only 1-2 seconds on a fast connection. If you have zero of that content cached locally and are on a mobile or just not-fast connection it'll be way more than 1-2 seconds. Your "solution" is one of the ones responsible for locking up mobile browsers all over the place, because the browser still has to deal with the entire DOM, and it's often done way inefficientl…

> 2mb html file, + whatever else for initial load?

nothing else because all images are already inlined as svg as well as all styles and the mentioned js code

> Your "solution" is one of the ones responsible for locking up mobile browsers all over the place, because the browser still has to deal with the entire DOM, and it's often done way inefficiently.

I only came up with doing it this way after previously having build the same app using react and old devices (eg android pre chrome) could not handle all the vdom diffing and add/removeNode.

Our users preferred a slightly longer initial load (even 10 seconds) and lightning fast interactions afterwards over fast initial load and sluggish UI for all the time using the app.

When doing client sit rendering you would still have to transfer and parse little chunks of json all the time.

As it turns out browsers are really good at handling even huges DOMs as long as you do not manipulate it to much.

Granted this way only works if you have a limited set of states/pages (eg a few thousand).

Re: None of my projects want to be SPAs

#50

Post by masklinn »

arcticwombat wrote: post #45
korm wrote: post #41

Earlier quoted context omitted.

I hope we don't go back to MVC for everything. I think we just have to use the right tool for the job. If an app is highly interactive or will have frequent data updates, or if it's supposed to be used almost like a native app, a SPA is the perfect way to achieve this. If it's going to be like most sites, traditional MVC will probably be better. Not that react isn't great for traditional websites, I've just seen too…

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 larger static HTML pages is quite enjoyable.

Post reply on HN