Live data from Hacker News

None of my projects want to be SPAs

whatisjasongoldstein.com

261–270 of 362 posts

Re: None of my projects want to be SPAs

#261

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

If you are talking about events for $(document).ready type things -- there is a turbolinks event for page:load -- it's a copy/paste replacement.

Re: None of my projects want to be SPAs

#262

Earlier quoted context omitted.

Because I decided I like React? :P From my perspective, React is the thing with the problem: it doesn't have great state management for complex tasks / multi-component coordination. What I want to use is something like RxJS to manage such interactions and state, because it gives me a lot of power/control in a relatively easy way. One of the best options out there that I've seen is redux-observable, and thus Redux its…

Plenty of people pair RxJS with React, including PayPal and Netflix. There is nothing precluding you from doing so. What kind of point is this?

Netflix is one of the contributors to redux-observable as well.

Sure, you don't need Redux in the middle of the "oreo", but it's also not the "wrong" answer, either.

Re: None of my projects want to be SPAs

#263

Earlier quoted context omitted.

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…

> you're paying the bulk JS load cost of loading Redux

Redux is small.

> the latency cost of loading small parts as you go

The components are static JS split into files.

Pop those into a CDN and you get the best of both worlds.

Re: None of my projects want to be SPAs

#264

Earlier quoted context omitted.

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.

> some people go so far as to directly claim that something is good because Google uses it. Angular everything and everywhere and sprinkle it with Material Design!

Not a fan of Angular, am a fan of most of Material Design.

Re: None of my projects want to be SPAs

#265

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…

Not to completely disagree, but I've worked mostly with web based applications, not specifically static content (with few exceptions)... I find working with React and similar far easier for mid-large applications than most of what came before. I was optimistic around ASP.Net (webforms not mvc) and in practice it was a bloated mess without doing a lot of goofy things.

If you're building web applications, it's usually easier to build with components than to think in terms of web controls. If you can separate state slightly from the components even better. This is why react + redux scales well. It makes very little sense in smaller apps, or those that are mostly static. It makes huge sense when you have hundreds or thousands of components, and a lot of application logic and structure.

It isn't just because management wants an SPA... sometimes an SPA is the best option.

Re: None of my projects want to be SPAs

#266

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.

Yeah... "because google|apple|microsoft|ibm|facebook ..." is generally a bad idea on its' own merit. I do like React though. I like similar JSX tooling around inferno and preact too. It's just something close to what I wanted when first playing around with e4x with flash/flex and mozilla browsers.

Re: None of my projects want to be SPAs

#267

Earlier quoted context omitted.

sure, although modern browser apis mean the url bar can change in a reasonable way

What about tabs? SPA can make tabs troublesome. If I can't open a site in tabs it is broken to me.

I'm not sure when/why tabs should be an issue... it depends. To me it's a difference between localStorage and sessionStorage for the most part.

Re: None of my projects want to be SPAs

#268

Earlier quoted context omitted.

Because I decided I like React? :P From my perspective, React is the thing with the problem: it doesn't have great state management for complex tasks / multi-component coordination. What I want to use is something like RxJS to manage such interactions and state, because it gives me a lot of power/control in a relatively easy way. One of the best options out there that I've seen is redux-observable, and thus Redux its…

> From my perspective, React is the thing with the problem: it doesn't have great state management for complex tasks / multi-component coordination. What I want to use is something like RxJS to manage such interactions and state, because it gives me a lot of power/control in a relatively easy way. One of the best options out there that I've seen is redux-observable, and thus Redux itself is just the "stuff inside the…

> The observer pattern is mentioned in the Gang of Four Book[1], published in 1994. JavaScript first appeared in 1995. Observers predate Redux. You don't need Redux to use observers, and in fact there's nothing about React that is incompatible with RxJS.

Yes, and before I was using React+Redux+Redux-Observable I was using Cycle.JS and everything was RxJS and/or Xstream (an RxJS-like) observable-based patterns.

As I said, this stack is a useful "oreo" for my needs right now. I understand if "oreo" isn't your cookie of choice.

> at the very least I think we can agree that "Doing one thing well" in UNIX means not creating a bunch of new problems that you need other tools to solve.

Again, I think the problem here is that we are disagreeing on what the problems even are. Again, I don't think these tools "create problems", I believe they solve very specific problems, and yes very "unix" in that way of solving as specific a problem as they can and no larger, and leave other problems that already existed untouched, whether or not they were in play, because again that's the philosophy here. React is "just" a view layer with a bare modicum of state responsibility. Redux is "just" a state layer. Redux-observable is "just" a tool for handling state side-effects. They don't need to solve every development problem, this isn't Angular. Similarly, they aren't the only tools for the job. There are several alternatives to each part of that stack (as others in this thread keep pointing out), this is just the one I've chosen for my projects right now.

Re: None of my projects want to be SPAs

#269

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.

Having worked on web based applications (not sites) for a couple decades, I have to agree... I'm a fan of either SPA + Node API (other APIs behind it as needed) or, can it build to a static deployment. I push to one end or the other.

Re: None of my projects want to be SPAs

#270
post #241

Earlier quoted context omitted.

Depends pretty much where one wants to work. Outside the software business, on companies whose focus is totally unrelated to software, no one cares that much how things work. They just have a couple of devs, or hire some freelancers do do some stuff, no matter how, it just has to look pretty.

And they pay them peanuts compared to software businesses.

Speaking from experience, not necessarily.
Post reply on HN