Live data from Hacker News

None of my projects want to be SPAs

whatisjasongoldstein.com

111–120 of 362 posts

Re: None of my projects want to be SPAs

#111
Nothing wrong with the concept of SPAs. It's just these modern front end frameworks leave a lot to be desired. None of them simplify complexity and modularity is an illusion. Most of your components can't be reused in another project.

Additionally these frameworks are harder to debug thanks to leaky abstractions.

The only front end abstraction I've seen do it correctly is Elm. I'm not saying Elms' pattern or language is good or correct; (I have no comment about that) I'm saying that the abstraction isn't leaky. No javascript errors in Elm, just elm level errors. React Vue and all these modern frameworks need to be handled the same way.

I know technically that react is just a framework and not an entire language over javascript, but the ways and technology React is typically bundled with makes it a leaky abstraction and the common use case should be handled.

Re: None of my projects want to be SPAs

#112

Back when I was doing React, what pulled me in was that it WASN'T a framework for SPAs. What I got from it was the ability to build UI widgets (components, in React terms) that worked within a page, and were composable with other UI widgets. With that approach, you really wanted to keep every component self-contained. That meant a lot of bookkeeping with passing events back and forth between parent and child widgets,…

> These frameworks add a huge amount of hidden global complexity just to avoid having to pass parameters to components, which is the simplest thing to do. Redux offers a few benefits: 1. Allows you to keep your global application state 100% predictable by treating it as a pure function of an event stream (dispatched actions). This makes it trivial to test. 2. Allows you to "time travel" the state of your store using…

What are some "costs" you think it has?

Re: None of my projects want to be SPAs

#113
post #92

Earlier quoted context omitted.

I'm surprised you dislike Redux simply because it's a form of global state. Sure, global variables make debugging difficult when you don't know which function changed them where and when and why. But that doesn't happen if you keep your functions pure and only make changes from within reducers – at least that's my experience. (Boilerplate, yes, Redux adds that. But at least it's all in one place, and not scattered th…

Anecdotical comment: While studying computer science, I almost fail a test because I used global variables. Since then I avoid them like the plage, and I get rashes when I see them. And I thank my teacher for knocking the bad habit out of me. So when I see global variables beyond the initialization of core objects, I take it as a bad code smell.

Global variables are different from global state. Every program has global state, whether you like it or not. Global variables are a poor way to declare, mutate, and read global state.

Re: None of my projects want to be SPAs

#114

Earlier quoted context omitted.

> These frameworks add a huge amount of hidden global complexity just to avoid having to pass parameters to components, which is the simplest thing to do. Redux offers a few benefits: 1. Allows you to keep your global application state 100% predictable by treating it as a pure function of an event stream (dispatched actions). This makes it trivial to test. 2. Allows you to "time travel" the state of your store using…

What are some "costs" you think it has?

Redux definitely adds an extra layer of complexity to a project and a lot more boilerplate. That is what lead to Dan's famous blog post "You Might Not Need Redux" from 2016.

https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

Re: None of my projects want to be SPAs

#115

Earlier quoted context omitted.

> Redux was the solution to server side rendering state. Could you explain what you mean by "server side rendering state"?

Server side rendering mounts your application in the server and sends down html along with an initial state. The client receives this initial state and uses it with the html to glue together a working UI on the client. This removes the massive JS bloat into raw html and split JS for each component. Instead of sending 3MB of JS, you send only the JS needed to render the current page... and send additional JS as a user…

Okay, but that's an even worse idea than what I've seen Redux used for. Now you're splitting the UI between client and server in a completely custom way, that adds even more complexity. Worse, the performance is likely to be worse because now you're paying the bulk JS load cost of loading Redux AND the latency cost of loading small parts as you go: the worst of both worlds. I doubt this is what the Redux folks had in mind, but if it was, it's even worse than I thought.

Re: None of my projects want to be SPAs

#116
post #80

I feel as if many sites that used to be fine and work well have regressed in usability and features and introduced unexpected behaviors and bugs since the SPA paradigm seems to have taken over. This seems especially true for many corporate, bank, shopping brand sites, etc. An example is the Capital One 360, Chase, and AMEX sites and even Reddit. Even JustWatch.com seems like it's fairly polished, still has it's quirk…

Fellow JustWatcher here, care to elaborate which quirks exactly you mean? Back when SPAs were still pretty new, we took the bet to make one with a pretty large surface area and despite a lot of issues (SEO especially) so far we're pretty happy with that decision.

Infinite scroll, showing the details, clicking back sometimes doesn't bring me back to where I left off. Same when scrolling horizontally for example on the New releases I'll have to start scrolling right again after click on the details.

Honestly, your website is probably the best implementation of a SPA website with multiple pages I have ever seen I can recollect. It still has quirks though. I just don't see why you would want to make a website like this a SPA.

Does that help a little? I wrote this quick, off the top of my head. I can try and provide more details maybe in an email or some other communication means too.

Re: None of my projects want to be SPAs

#117
post #113

Earlier quoted context omitted.

Anecdotical comment: While studying computer science, I almost fail a test because I used global variables. Since then I avoid them like the plage, and I get rashes when I see them. And I thank my teacher for knocking the bad habit out of me. So when I see global variables beyond the initialization of core objects, I take it as a bad code smell.

Global variables are different from global state. Every program has global state, whether you like it or not. Global variables are a poor way to declare, mutate, and read global state.

> Every program has global state

Could you explain what you mean by this?

My intuition here is that what you're saying is true in a trivial sense, but that most state CAN BE (and should be) local if you're breaking your programs into reasonable building blocks.

Re: None of my projects want to be SPAs

#118

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.

This is one page/app I built that way [0]. In this particular case it's not even fully optimized (eg js and css not minified, loads some external images...)

[0] https://app.ishl.eu/

Re: None of my projects want to be SPAs

#119

This may be a mean thing to say, but basically I think SPA's are massively overused, because developers want to demonstrate that they can do them. Why? Because big companies like Facebook and Google use them. Why? Because they actually are doing things that require them. 99% of the SPAs in production are things that should have been done the old Rails/Django/Laravel way, but that would not set you up as a developer w…

Yeah, some people go so far as to directly claim that something is good because Google uses it. And when Google uses it, it probably IS good for solving Google's problems. But most people aren't Google and don't have Google's problems.

Re: None of my projects want to be SPAs

#120

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 recently started a hobby project and initially went with a JS solution. But when I had to start deciding on auth, maybe an orm, routing, db layer, and templating, I said fuck it and installed Rails.

Previously I had never built a real product in Rails, only the book store tutorial. I'm really happy with Rails so far. I don't have to worry about a lot of shit I had to worry about in JS land and now I can focus on the app itself.

Post reply on HN