Live data from Hacker News

None of my projects want to be SPAs

whatisjasongoldstein.com

31–40 of 362 posts

Re: None of my projects want to be SPAs

#31

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.

Re: None of my projects want to be SPAs

#32
I see the same thing happening on the front end that I saw happen on the back end with big data. Just because it fits better into Google and Facebook's Enterprise patterns doesn't mean it will work for everyone. Very few companies need Hadoop, probably as few as need react

Re: None of my projects want to be SPAs

#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), then show images, then you don't care if the rest of App and all the js and 3rd party crap take another 2.5s and 3mb to load, The user will do a bit of reading and picture watching, before using a button or input field. However if they're on the go and loose connection, now they have a fully functional back button in their browser to read the next or previous cached html/css content.

Re: None of my projects want to be SPAs

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

With context api and hooks you don't need redux or mobx.

Not that either one was really all that necessary in the first place anyway.

Re: None of my projects want to be SPAs

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

Re: None of my projects want to be SPAs

#36
The latest project I'm currently working on I got to choose how to build. It is an internal CMS. I went with Rails API, React, Material-UI. So far, I like it.

I like separation. I know that one side ( ruby, rails, gems, pg, sql etc ) is all about data -> one mindset.

Another side is about views ( js, css, html, multiple select, date pickers, autocompletes etc ) -> different world.

I build my assets in one place, I work with my data in other. I wear one hat as a backend guy, and when I need refocus completely on front end work.

I wouldn't argue it's easier, but I think it's easier for me. I like it better.

Plus, the API will be consumed eventually by user-facing site and apps.

Re: None of my projects want to be SPAs

#37
post #26

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.

In the last Angular app that I inherited every menu on the page needed a separate call to populate it. It probably wasn't the best written app. I think if it had been plain Django with some jQuery for front end validation the size code could have easily been cut by a half or more.

Re: None of my projects want to be SPAs

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

I suspect nisten is referring to server side rendering using React.

Re: None of my projects want to be SPAs

#40

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

this is not just one simple drop in replacement, well it is if you load only html, but pages are usually html + js, even for "old" mvc. so because there is no page relaod you have to rethink all your events, objects and so on.

so if i have to rewrite my js with this just so i could fake SPA then benefits are so much smaller

Post reply on HN