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

121–130 of 362 posts

Re: None of my projects want to be SPAs

#121

Post by endymi0n »

b3b0p wrote: post #116
endymi0n wrote: post #104

Earlier quoted context omitted.

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

Hey, that's super helpful, thanks!

Why SPA? Well, a good question indeed. Actually, we're cross-compiling the same code for the webapp onto iOS and Android targets with build flags, where we're leveraging more platform features (i.e. geolocate cinemas).

Also, it lets us make the experience itself much more snappy once you're on the page, as there's just content to be re-loaded. You can switch tabs, we can remember scroll positions, stuff like this.

Stay tuned though for our completely rewritten release based on very recent technology, I'm hopeful this will change your perception about SPAs on large sites coming in March!

Re: None of my projects want to be SPAs

#122

Post by Illniyar »

Do we really need to defend SPA every other week? The market, users, product, ui/ux designers and the vast majority of developers decided that SPA is a better user experience.

Page loads greatly degrade the user experience, especially when you have long lag (which for many of us the reoundabout time is longer then the download time of 100k).

Even if you make your site extremely lean, it's still a worse experience, and let not forget that for the majority of sites lean is far beyond them (not the least because you must integrate third party code such as social and analytics or fade into obscurity against those who do)

So some developers feel that the old way of doing things is just fine. There are always some of those. Probably the same ones who surf the web with js disabled. This is not even remotely what the average person expects and anyone who thinks they can build a website like that and compete are delusional (and hacker news is perhaps the exception that proves the rule. Even google is not html only anymore)

Re: None of my projects want to be SPAs

#123

Post by mosdl »

ghthor wrote: post #113
jorgeleo wrote: post #106

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.

Redux means everything is global state which is terrible. A grid I render now has to have global state and most projects forget to do any cleanup - so you end up with all this junk in redux that isn't needed anymore, clogging up memory.

Re: None of my projects want to be SPAs

#124

Post by jmkni »

WrtCdEvrydy wrote: post #103
octosphere wrote: post #88

Earlier quoted context omitted.

If you have Javascript disabled, all you should see is a blank white screen, and if you're lucky a small note saying 'This site requires Javascript to work correctly'. That's what a SPA is

React Server Side rendering takes care of this... but most people don't know how to do it. Without JS, Server Side JS defaults to good old school MVC.

When you are adding a new framework to render your single page app on a server, that's the point to stop and re-evaulate your technical decisions IMHO.

Re: None of my projects want to be SPAs

#125

Post by [deleted] »

kerkeslager wrote: post #119
rossdavidh wrote: post #108

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.

[deleted]

Re: None of my projects want to be SPAs

#126

Post by johannes1234321 »

kerkeslager wrote: post #117
ghthor wrote: post #113

Earlier quoted context omitted.

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.

You have information which has global nature, used in multiple sorts of the application. This could be, among other things - STDIN/STDOUT/STDERR file handles - static configuration - some parts of runtime configuration - application info (in a game maybe current score, current level, active players, ...)

All that information exists only once and is needed in many parts.

Re: None of my projects want to be SPAs

#127

Post by kokokokoko »

joshuacc wrote: post #99
kerkeslager wrote: post #79

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…

I have yet to see a long term project built with Redux that was maintainable. That seems to be the common denominator in React projects that do not survive technical debt accumulation.

The issue with Redux is that it encourages side effects in components. After a while people are dispatching all over the place and you end up in a similar situation as you were with keeping track of JavaScript events. All of a sudden something stops working because someone removes a component that is dispatching on a timed interval etc.

If you can convince and enforce that all Redux activity only happens at the root component, you should be okay. But the reality is that once you have the discipline to only mutate state in your root component, then setState tends to be more than enough for anything but very large and complex interfaces.

With that said this article has the author implementing their homebrew bespoke event system which is likely even worse. This was a very popular and much maligned anti-pattern during Angular 1.x days. This article is suggesting the absolute worst possible idea for maintenance.

What kills the maintainability of React and similar frameworks is tracking down what component did what. Unfortunately, in real world examples, in my experience, Redux increases that issue and ultimately leads to a very difficult application to maintain long term.

Re: None of my projects want to be SPAs

#128

Post by _coveredInBees »

supermw wrote: post #34
wickoff wrote: 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.

I've still found the concept of computed properties in mobx to be extremely useful (and I say this as someone who relies on regular React + SetState 90% of the times). MobX encourages you to think about representing your state in the minimal possible representation and to heavily use computed properties that depend on this smallest, irreducible state representation for everything else. Switching to this mindset makes developing more complex components (especially UI/forms) a breeze. I also find MobX to be great for async things and much easier to handle than via setState. Using setState alone in these types of complex components ends up being really tedious and prone to errors (largely driven by the async nature of setState updates).

Re: None of my projects want to be SPAs

#129

Post by brightball »

rossdavidh wrote: post #108

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…

You're not wrong.

There are clearly good uses for SPAs, but the author is totally correct that most sites are "open, check, close" experiences.

If it's not essentially a web based, desktop app...it's much harder to justify. Real tools. If it's not a tool and the user workflow is "open, check, close"...it's serious overkill.

Re: None of my projects want to be SPAs

#130

Post by _coveredInBees »

wickoff wrote: 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.

Yup, MobX has made developing more complex React components / UIs a sane endeavor once more. Every time I use MobX, I think to myself that it can't possibly be this simple...then run the code, and pick up my jaw from the floor because everything just worked the way you intuitively thought it should.

Meanwhile, relying on setState alone for complex components ends up being very error prone and tedious. I still rarely use MobX for global state because I prefer the original appeal of React in terms of making modular, reusable components, but I often use MobX as the state mechanism for my more complex components and bypass having to rely on setState altogether for those components.

Post reply on HN