Live data from Hacker News

None of my projects want to be SPAs

whatisjasongoldstein.com

211–220 of 362 posts

Re: None of my projects want to be SPAs

#211

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…

Well, SPAs are attractive even for websites that don't particularly benefit from them because of the technical attractiveness of having the website be like any other client that consumes your server's API.

> SPAs are attractive even for websites

> having the website be like any other client that consumes your server's API.

Did you fall hybernated sometime in the AJAX era? Now it's state synchronization over GraphQL run on dockerized autoscaling cluster. Satan only knows perhaps how to make that retarded bastard to work in a web browser. I have yet to encounter a backend/system developer who doesn't consider designing and implementing a complete and functional REST API a grunt task.

Re: None of my projects want to be SPAs

#212

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…

As someone who started developing not long ago, is there any reason to not make an SPA when it is the workflow you are used to? I just don't see a practical difference between SPA or not. The argument I usually see is that its harder...but like me I expect there are more and more people who have learned this way first. I mean for SEO sure, but I usually am not concerned with SEO at all.

Building an SPA for every single project is like using a semi-trailer to commute everywhere you go. Sure, it will always get you where you need and sometimes turns have to be taken pretty wide, but what's the downside?

Well, if you're destination is just 2 blocks down the road then why not walk? If you just need a simple page and the content doesn't need to be updated often, why not some flat HTML/CSS/JS?

Many times SPA frameworks are used because it's flashy and more exciting than writing basic html and css, but more often than not that's all you need.

Re: None of my projects want to be SPAs

#213

Earlier quoted context omitted.

As someone who started developing not long ago, is there any reason to not make an SPA when it is the workflow you are used to? I just don't see a practical difference between SPA or not. The argument I usually see is that its harder...but like me I expect there are more and more people who have learned this way first. I mean for SEO sure, but I usually am not concerned with SEO at all.

Building an SPA for every single project is like using a semi-trailer to commute everywhere you go. Sure, it will always get you where you need and sometimes turns have to be taken pretty wide, but what's the downside? Well, if you're destination is just 2 blocks down the road then why not walk? If you just need a simple page and the content doesn't need to be updated often, why not some flat HTML/CSS/JS? Many times…

I didn't consider small static sites. I agree with that and have done some landing pages that way that stand in front of SPAs. I guess I was commenting on OP wanting to use Rails or Spring MVC for views instead of only using them for APIs.

I'm not sure what the term for it is, monolith maybe.

Re: None of my projects want to be SPAs

#214

Earlier quoted context omitted.

In order to have dynamic UI you either have to use jQuery or SPA library like Vue or similar. For me the major advantage of vuejs over jquery is the way data drives UI

But... people had dynamic UIs before jQuery and Vue. The main benefit of jQuery was back in the days when the browsers were so different from each other, but that's not the case anymore. I'd recommend learning some vanilla JS before thinking that you need jQuery/Vue/React to create dynamic UIs.

The difference is imperative vs reactive UI. The impact of this is hard to overstate.

Re: None of my projects want to be SPAs

#215

Earlier quoted context omitted.

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

>exists only once and is needed in many parts.

I think many people could argue that this concept itself is a bit misguided. There are plenty of application patterns and architectures that help you move stateful data around your app and translate it for the components who need to consume it or change it, while hiding it from components in the tree which do not interact with or care about the state.

If you have many different components in your app that all need access to the same state data, and they exist at different levels in the hierarchy, maybe you need to re-think your component structure rather than figure out a way to inject mutable global state everywhere?

Re: None of my projects want to be SPAs

#216
post #172

There is a slight advantage of separation in frontend & backend - writing tests for an API-only backend is so easy. On the other hand, the frontend SPA still needs tests, and I have no idea how to make that trivial yet. P.S. If you folks want a really small react-like SPA, I recommend either https://mithril.js.org or https://riot.js.org And you can avoid state management complexity by using a pattern like http://meio…

Testing is easy in Angular. (Thanks to the everything is an object approach.)

https://angular.io/guide/testing#component-class-testing

https://angular.io/guide/testing#service-tests

Re: None of my projects want to be SPAs

#217

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…

> 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. Unfortunately this is another side effect of the broken hiring process in IT. Recruiters are scanning resumes for the hottest buzzwords, hiring managers want people who have experience with whatever is currently hyped, so developers naturally steer towards those technolo…

100% correct, and I'm guilty as charged. If leadership likes the sound of SPAs, and my next job wants me to have experience with SPAs, I'm using SPAs.

Re: None of my projects want to be SPAs

#218

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…

It's similar to people gravitating to NoSQL when they probably actually needed a relational database because they don't really think about their data model and how it will be accessed.

That being said, as someone who has done a lot of infrastructure work, I do like web technologies that can fit into something like serverless and Ruby/Rails really isn't there. Speed, file size, and boot time all become much more important. Or if you can make it work, fully static pages that can live on S3/Cloudfront and any dynamic needs are abstracted away to API gateway/Lambda and pulled in.

I would much rather have an app running inside of Lambda instead of having to manage a load balancer and AWS auto-scaling, or even elastic beanstalk.

So many problems can be dissolved down into people picking the wrong tool for the job.

Re: None of my projects want to be SPAs

#219
post #163
post #123

Earlier quoted context omitted.

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.

Nothing is forcing you to put everything in Redux. If state only has relevance to a single component then keep it in that components state, Redux works perfectly fine with this approach.

And when the state has relevance to two components? Now it's okay to make it a global, because we can't be bothered to type "prop = value"?

I'm just not buying this argument. People add Redux to projects because they intend to use it, and there's almost never a case where a piece of data is actually needed in enough places that it should be global. It's certainly not common enough to justify importing a whole framework for managing global state.

Re: None of my projects want to be SPAs

#220
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…

> 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. Sticking to reducers IS a good idea and it does make things a bit better. The problem with global state goes deeper than that, though. Often, as you learn about the s…

If you're giving me the choice between dealing with this:

> Often, as you learn about the structure of the data, it becomes useful to change how the data is structured and stored. In global state, you can change that in reducers, sure, but then all the places that render that data have to be updated. You don't have the option to represent the same data in different ways that might be more suitable for different parts of the application. You either have to change them all at once, or synchronize a bunch of states that really contain the same data (which is even worse).

or this:

> With independent components, you do spend some time synchronizing data across components

I'm not even hesitating before I choose the first option. My editor, static analysis, and the mystical art of the function can give me all sorts of help with the first problem. Good luck with those sync bugs.

Post reply on HN