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

301–310 of 362 posts

Re: None of my projects want to be SPAs

#301

Post by pault »

kerkeslager wrote: post #237
poink wrote: post #220

Earlier quoted context omitted.

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…

You selectively quoted me, ignoring where I explained that synchronization isn't as big of a problem with passing properties into components. I already addressed your concern. Don't selectively quote me, it's rude and just shows you aren't following the conversation. Futher, Redux doesn't solve synchronization issues in situations where you can't represent the data the same way. In the most complicated situations, it…

> Futher, Redux doesn't solve synchronization issues in situations where you can't represent the data the same way.

I would argue that synchronizing data between multiple representations is an anti-pattern, and the exact anti-pattern that redux, with its emphasis on a single source of truth, was designed to solve. Synchronizing state is almost always going to lead to hard to diagnose bugs in edge cases. There's even a blog post on why it's a bad idea on the official react blog [0]

My solution to this problem is to use computed values generated by a library with memoization like reselect. I structure my data as close as possible to the API data models and use selectors to transform the models into the data structures that disparate UI components require. If you need to change your UI component, you don't need to refactor your store, and if you need to change your store structure, you don't need to refactor your UI components.

[0]: https://reactjs.org/blog/2018/06/07/you-probably-dont-need-d...

Re: None of my projects want to be SPAs

#302

Post by korm »

kerkeslager wrote: post #200
qudat wrote: post #145

Earlier quoted context omitted.

> I have yet to see a long term project built with Redux that was maintainable. The only maintainable projects I have worked on in terms of web apps have been with Redux. Redux is not great for simple projects, it is great for medium and large scale projects. > All of a sudden something stops working because someone removes a component that is dispatching on a timed interval etc. That's the problem: react and redux a…

> Redux is not great for simple projects, it is great for medium and large scale projects. I'd say that the only times I've seen Redux work effectively at all is when the project was small enough that the complexity remained manageable. > > All of a sudden something stops working because someone removes a component that is dispatching on a timed interval etc. > That's the problem: react and redux are not enough for l…

> but you'll excuse me being skeptical that introducing more complex tools will solve my complexity problem

I'm a consultant and in my experience this misconception is by far the most common source of problems in redux projects. Redux is a very small and simple thing so you have to build a framework around it. Even redux-thunk isn't enough - that's only 5 lines of code.

I wouldn't recommend react/redux for public facing sites if there's no experienced, pure frontend team. A more batteries-included kind of framework would be better. There's a lot of thinking to do and hardcore levels of scaffolding to maintain before writing anything useful and maintainable with redux. But it can absolutely lead to maintainable applications.

Also, I've never seen any homegrown "vanilla" frameworks or data stores work well as complexity increases. It usually ends up as spaghetti, especially with a growing team + growing business demands. Or best case a poor re-invention of the wheel. There must be brilliant counter examples but they're probably rare, I may never have the pleasure of working with one.

Re: None of my projects want to be SPAs

#303

Post by dwaltrip »

tobr wrote: post #54
lucidone wrote: post #21

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…

For a component here and there React is a pretty bad choice because of its size. Svelte could be a more suitable option, but I’m not so sure it passes the magpie test.

Magpie test? I couldn't find an answer on google.

Re: None of my projects want to be SPAs

#305

Post by rossdavidh »

eeeeeeeeeeeee wrote: post #218
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…

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

Yeah to be honest, even RoR/Django/whatever is often more than is necessary. Sometimes static HTML/CSS is what's necessary. A lot of the time, really. I wonder what percentage of React websites could be well served with static HTML and at least one employee who knows HTML.

Re: None of my projects want to be SPAs

#306

Post by rossdavidh »

nickjj wrote: post #199
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…

Yep exactly. I remember a while back I wrote a blog post where the main topic was "You're not Google (unless you're Google)"[0]. It was related to micro-services but the same thing applies to SPAs too. [0]: https://nickjanetakis.com/blog/microservices-are-something-y...

Well put. Imagine if every building in a city were built with a foundation capable of supporting a skyscraper, because what if you eventually need a skyscraper?

Re: None of my projects want to be SPAs

#307

Post by yellowapple »

JetSpiegel wrote: post #286
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…

> Because they actually are doing things that require them. Citation needed. G-Suite's admin pages are half "modern" SPA monstrosities that suck up my RAM and peg my CPU to render a bunch of whitespace with bits of information strewn around, and ugly but functional regular pages whose performance is killed for being framed inside a SPA frankenapp.

Right? Sure, there are Google products that certainly warrant being SPAs (like Google Docs), but the vast majority should be possible to implement without a single line of Javascript at all, let alone as a single-page application.

Re: None of my projects want to be SPAs

#308

Post by yellowapple »

hombre_fatal wrote: post #144
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…

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.

You can do this with a non-SPA website just fine if the website's backend is the API client. Sure, it adds an extra layer of indirection between the browser and your data, but if the separation of concerns is really your goal, then that's probably as good as it gets.

Re: None of my projects want to be SPAs

#309

Post by yellowapple »

sl1ck731 wrote: post #204
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…

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.

It's nice when I don't have to enable JavaScript just to use a website. My battery appreciates it at the very least. Forcing me to run arbitrary Turing-complete code from the Internet just to, say, read an article or buy something online is not okay, especially when that code exists solely to either 1) spy on me or 2) reimplement half of my browser.

Re: None of my projects want to be SPAs

#310

Post by yellowapple »

repsilat wrote: post #140
s_y_n_t_a_x wrote: post #135

Earlier quoted context omitted.

It's really simple, if you're developing a web app, use a SPA stack. If you're developing a web page, use the minimal amount of tech you need on top of HTML, ideally where the HTML functions without JS.

Does that help much? The distinction between "web app" and "web page" seems fuzzier than the question "would a SPA lib/framework be useful here?" Is Reddit a web app? Is Twitter? Facebook? They all started with server-generated HTML, all kinda feel "document-like", all of them involve scrolling (if that means anything.) Is the "app" boundary further along the chain, like at Google Docs? I think instead of trying to c…

"Is Reddit a web app? Is Twitter? Facebook? They all started with server-generated HTML, all kinda feel "document-like", all of them involve scrolling (if that means anything.)"

All three of these are examples of websites where JavaScript should be entirely optional. With the exception of the realtime chat functionality in reddit and Facebook, there is very little that any of those three platforms couldn't do exclusively with server-side-rendered HTML and CSS. It might be ugly, but it'd be usable. Any client-side scripting should build on top of that and implement the fancier features.

Post reply on HN