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

21–30 of 362 posts

Re: None of my projects want to be SPAs

#21

Post by lucidone »

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 to use it well, including myself).

Most apps are fine serving html, using plain old boring forms, and having the odd React or Vue component where necessary to do some heavy lifting for user interactions. Moreover, it's a lot quicker as a small team to iterate.

Re: None of my projects want to be SPAs

#22

Post by taeric »

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.

Re: None of my projects want to be SPAs

#23

Post by DanielBMarkham »

A SPA should be the emergent result of creating an application that does something people want, not a goal in itself. Your builder doesn't show up at your house to put on a new deck and go "Gee, I really hope I get to use this 20-pound sledgehammer on this job. I hear it makes great projects"

If you start with how it's going to end -- it's not going to end well.

Having said that, what you're most likely seeing is that a ton of tools and frameworks are built for no other reason than 1) Coders need something to create to show other coders how awesome they are, and 2) People want something that works like everything they know -- it just does these one or two new things

This is a great way to make a mess over a decade or two, and you're right for waiting it out.

Make a SPA if you need a SPA. Key question: How do I know whether I need a SPA or not? (Or whether React makes sense, etc)

Re: None of my projects want to be SPAs

#24

Post by laszlokorte »

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

- result: not so fast initial load (1-2 seconds) but really fast interaction afterwards even on old lowend devices, almost no time spent running js/react/vdom. even some scrolbugs I had to work round before when using react (eg replacing dom nodes but keeping scroll position of a parent container) resolved on their own.

Re: None of my projects want to be SPAs

#25

Post by shusson »

dictum wrote: post #20
supermw wrote: post #9

Why do people insist on comparing the initial frontload of a SPA to the page load of every page in their SSR web app? Once a SPA is loaded you can send tiny crumbs of data faster than any significant SSR.

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.

Re: None of my projects want to be SPAs

#26

Post by ivanhoe »

arcticwombat wrote: post #7

I have to say my experience tracks this too. A lot of the "modern" toolsets just aren't worth the extra fluff they add. Writing SPA's in React, Angular, etc. tend to result in a very heavy first page load, then api calls with poor UX for all actions.

Don't regular web sites do exactly the same? They also usually pack all JS and CSS into two big files in order to reduce the number of requests on the initial load, right? And beside in SPAs you can split the code and lazy load it to reduce the load.

Re: None of my projects want to be SPAs

#27

Post by duncan-donuts »

victor106 wrote: post #18
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

Can you use Turbolinks with a Java backend?

Yes, you can use it with whatever.

https://github.com/turbolinks/turbolinks/blob/master/README....

Re: None of my projects want to be SPAs

#28

Post by wickoff »

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.

Re: None of my projects want to be SPAs

#30

Post by realusername »

Also one of the things not listed here is the added complexity of an SPA, the routing bugs, the old browsers bugs, the added complexity of splitting js files so the initial load does not become too big, the data storage...

I'm currently maintaining alone two large websites and only one of them is an SPA, that's definitely the harder one to maintain by far.

Post reply on HN