None of my projects want to be SPAs(whatisjasongoldstein.com) |
None of my projects want to be SPAs(whatisjasongoldstein.com) |
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.
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://meiosis.js.org
I don't want to go back to Rails/PHP/Python though. I like having a REST/GraphQL API. With Hasura I don't have to worry about backend anymore for 80% of the cases.
What I'm doing right now for the front end is using Jekyll with Vue. It's really liberating not having to worry about a router or managing application state anymore. For certain in-house projects I don't even have to use Babel or Webpack anymore and still get to use Async/Await.
Maybe that'll change if I decide to build games with HTML/JavaScript/CSS or want to make some sort of online version of a desktop program, but nothing in my current ideas list is app like enough to really warrant the SPA setup.
so, basically a "functional" front-end view-framework for client-side behavior, but with no routing.
1. Tons of existing jQuery components.
2. Ten of custom, loosely coupled ones.
3. Built-in PubSub for their communication:
$(document).on("custom-event", function() {...})
And you can do any SPA out there. Or not SPA.
I get the definition, but I don't see a lot of problems and etc .... necessary a part of SPAs.
Lol, a 3 year solution. I immediately feel sorry for the future devs jumping into a codebase like that on New Year's 2023 trying to figure out what broke overnight.
When you start thinking about field validations and having to duplicate them client and server side, it makes even more sense.
The speed benefits are noticeable on sites where you're doing a lot of internal navigation. But you can just as easily make a slow SPA (see JIRA).
So I guess in the end, do whatever takes less development time. Which usually isn't an SPA, just because there isn't really a good framework that reduces effort required. Rails and turbolinks are pretty legit.
Mr Goldstein would have known this if he had visited the Meteor blog (https://blog.meteor.com/) and Meteor forums (https://forums.meteor.com/).
It's a great tool if that is your goal. Otherwise why spend the extra effort?
Without JS, Server Side JS defaults to good old school MVC.
I had actually never seen that written solely as SPA even though I've worked as a react dev for 2 years now in Canada. I guess the acronym really is going obsolete.
IE. Purely JS driven, no browser-page loads after the initial page has loaded.
Are there any barebones tutorials out there for CRUD apps that don't require Node.js, Python etc, and can be learned using PHP, MySQL and HTML?
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)
I used a lot of applications out there that aren't SPAs, I browse with JS turned on, and I believe that SPAs are nice in certain use cases, but for a large portion of web applications, you are primarily doing simple CRUD work, and don't need an SPA for that.
A proper example is something like: "Parking allowed on Fridays", which is an exceptional case to a rule that is implied: "No parking any other days."
Just a heads up, feel free to ignore.
If we are going by wikipedia definitions, then: "A rural village is "always" quiet. A local farmer rents his fields to a rock festival, which disturbs the quiet. In this example, saying "the exception proves the rule" is literally incorrect, but it is used to draw attention to the rarity of the exception, and to establish the status of the village prior to the exceptional event. "
Seriously, I've tried looking it up... https://acronyms.thefreedictionary.com/SPA
These, combined with Angular CLI or Create React App, allow me to be just as productive as the pre-spa days
Nobody worth their salt would recommend coupling display components and database manipulation together in an iOS or Android app. A webpage is the same thing, because it's not running on your server, it's running in the browser on the user's computer.
With this blog post, like most "I don't like X technology" blog posts, I find myself asking, "does the author not like this technology, or has he not taken the time to become a real SME in it?"
We had a SPA using OAuth.
I spent a few weeks adding docs, ran Swagger codegen, then declared it finished. Every call our front-ends used was now part of an API. Then we just trimmed out the parts we didn't want to officially support.
They override routing, they override SEO, they make it hard to use build in browser tools, etc, etc.
I have also witnessed discussions where management admits that they want something done in an SPA so that they can show that work to their investors, as a means of getting funding to do other projects. So basically the same reason, except for managers to impress investors instead of developers to impress potential employers.
Not saying all SPAs are mistakes; some uses clearly are not. But most of them are.
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 technologies.
So a developer may even be aware it doesn't quite make sense to use a single page architecture, but they know that if they have it on their resume it'll help them make more money at the next job.
It's a whole maladaptive signaling phenomenon that arises out of organizations overvaluing the wrong things in hiring.
Some may be aware, but certainly not everyone.
1: Google's abandoned webapp toolkit where you get all of the drawbacks of writing Java code with none of the benefits.
Angular everything and everywhere and sprinkle it with Material Design!
I'm learning Clojure at the moment, don't think I would have heard of Google Closure otherwise
People use SPA frameworks and make SPAs with them and those SPAs end up functioning exactly the same as any Rails/Django/Laravel site except the URL bar doesn't change. MVC is still the way the web is built, except for the people who got bored and wanted to make web development even harder than it already is.
YAGNI.
The problem with that is, blogs are a poor barometer for that sort of thing. Nobody needs to write new blog posts about tried-and-true things that are already plenty well documented. The more solid and stable a technology is, the less incentive there is for anyone to bother writing how-to blogs about it.
For me the major advantage of vuejs over jquery is the way data drives UI
Absolutely. This extends well beyond SPAs, too, in my experience. I recently burned part of a month explaining to my senior management chain why you don't just, literally, "do machine learning." Of course, it turns out that the ask was coming from the C-suite, who wanted to put it on a slide somewhere because "everyone is doing machine learning, we need to do machine learning."
[1] https://www.informationweek.com/big-data/ai-machine-learning...
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.
I've worked at places in all four quadrants of should/shouldn't and do/don't use microservices.
They're GREAT when they're the right fit.
Most websites aren't really a right fit and do fine with a classic webserver->DB setup.
But in reality most work is very simple. Most work does not require new shiny technology. Most work is insanely mundane.
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.
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.
Sure you can build with php, laravel, django. The promise of SPA is a clean separation of UI from the APIs. The same REST APIs that external customers use is the same API you develop on. See travis-ci as an example. It’s the same api that the mobile apps can use.
This separation allows the api to return very lightweight stateless responses. You can scale much better when there is less state kungfu.
The UI can manage the state in very responsive manner. No round trips, instant 60fps render.
And no JavaScript is not slow. It’s just that people don’t know it well and end up loading megs of bloated libs with a 1000 ad tracking libraries.
Don’t throw the baby with the bathwater.
Most of the time I find the initial delay loading/parsing the js to be more problematic than the often tiny speed increase of subsequent loads.
Furthermore, these days it takes minimal to no tweaking to get server-side rendered pages to load fast enough to barely notice the difference (in particular if the client-side is retrieving and parsing JSON in the background through an API request). Perhaps non-webdevs are even less likely to notice this stuff.
> If done well you can totally run offline.
That's definitely an advantage, but most SPAs I encounter don't offer offline functionality, or it's entirely unnecessary to offer it.
> Sure you can build with php, laravel, django. The promise of SPA is a clean separation of UI from the APIs. The same REST APIs that external customers use is the same API you develop on. See travis-ci as an example. It’s the same api that the mobile apps can use.
In some cases that's definitely an advantage. But it's entirely feasible to build an API-based backend and use that API internally for server-side rendering. If you want an app that plays nice with search engines you have to do this anyways.
> This separation allows the api to return very lightweight stateless responses. You can scale much better when there is less state kungfu.
That doesn't make sense to me. One of the biggest issues I have with SPAs is that you now have to deal with the backend state (DB) and a subset of this state on the client, which dramatically increases complexity (state management, sync, etc.). I rather like the old-fashioned approach where all state remains in the backend, except perhaps for the tiny bits you'd put in a cookie (and I suppose the URL could be considered client-site state too).
> The UI can manage the state in very responsive manner. No round trips, instant 60fps render.
How many apps do you use where you really need anything below say, sub-second rendering? Frameworks like Phoenix and/or caching can be much faster than that even (in the order of microseconds).
> And no JavaScript is not slow. It’s just that people don’t know it well and end up loading megs of bloated libs with a 1000 ad tracking libraries.
Clearly if so many SPAs are bloated Mb-size messes, it's not trivial to solve. And it's a problem you can almost entirely avoid if you keep the rendering on the server. After years of agonizing over bundle sizes, I find it incredibly liberating to not have to think about this anymore (much of the time, anyways).
> Don’t throw the baby with the bathwater.
I do agree that there are plenty of use cases for SPAs, but I also agree with many here who say they're very over-used.
I'll add that there are some interesting initiatives to have 'old-fashioned' applications that also get to be dynamic enough for many if most use cases. Phoenix LiveView [1], for example, takes advantage of very fast server-side rendering, websockets, and sending subsets of the templates as HTML snippets to the client, where morphdom simply diffs the HTML string with the element it's supposed to replace. With great performance.
[1]: https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera...
This may be even meaner, but they usually end up demonstrating they can’t. 99% of them are terrible. Even Google’s latest efforts are a bit on the slow, low-information-density side.
SPAs bring back the client-server architecture we had before the web. you build desktop clients that consume server-api's.
server-side html generation now feels like cruft and an awkward way of building applications.
And yeah, they're also common in situations where they're not the right solution because either devs want to turn their current employer into the next Google, want to build up the CV to look good when interviewing for Google or have a boss/investors who like shiny things in general.
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.
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.
Of course each application has different needs, but for large multi-developer UIs, I think a better option is to split your front end into distinct server based pages where you leverage React/GraphQL/SPA/PWA features for great DX within those pages. That way you can keep it fast and potentially limit some of the complexity.
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 come up with definitions to classify things (and probably argue for the meaning of those definitions from the conclusions we want to draw) we should ask,
- Will this help developers?
- Will this make users lives better?
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...
I mean for SEO sure, but I usually am not concerned with SEO at all.
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.
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, but while it was a lot of typing, it was all fairly easy, and if I wanted to change how an event was handled, it usually only involved a component and MAYBE the components immediately above or below it in the component tree. Data passed further than that was generally wrapped in objects and therefore didn't require code changes.
Then introduce Redux and similar frameworks, and I totally lost interest. It's as if the entire React community forgot all the lessons they learned writing Python and C programs in college and went back to creating global state. What in the actual hell? I wrote a good amount of code in Redux, too--I worked on teams that used it--so this wasn't just pre-judgment. 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.
And once you're doing that, you HAVE TO write an SPA, because any part of the page you want to be interactive gets pulled into Redux and your JS eventually eats the whole page. It's an infection.
When writing JavaScript now, I sometimes end up rolling my own version of the component style. It's an effective design pattern for UI widgets. But it hasn't been worth it to use React for a while now because the tooling and tutorials are all too conflated with Redux and similarly awful tools. And on a team, there's always the worry that someone on your team will infect your code with Redux and it will grow and consume your entire site. It's a real shame.
Most apps are fine serving html, using plain old boring forms, and having the odd React or Vue component where necessary to do some heavy lifting for user interactions. Moreover, it's a lot quicker as a small team to iterate.
Even JustWatch.com seems like it's fairly polished, still has it's quirks. So, I just end up using InstantWatcher.com instead. Hacker News works well as is too, except the search on the bottom can act up it seems once in a while.
Edit: How could I forget, Netflix. The UI, getting to the details of a show/movie. Browsing, discovery, searching, it all feels broken and unintuitive. The DVD site last I checked was still decent. Netflix seems like the poster child for usability and regression issues moving to a SPA.
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.
https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera...
I hope to see this idea brought to Rails, but the its websocket story doesn't seem there yet.
HTML rendering with Phoenix is lightning fast. https://www.bignerdranch.com/blog/elixir-and-io-lists-part-2...
so if i have to rewrite my js with this just so i could fake SPA then benefits are so much smaller
Compare this with rewriting your app as an SPA.
https://github.com/turbolinks/turbolinks/blob/master/README....
Turbolink is a crutch for people that are not able to server side render an html in a few milliseconds.
Then I tried mobx, I was able to write a small app after 15 minutes of reading the docs and now I love react.
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.
Not that either one was really all that necessary in the first place anyway.
I’d like to try and make it work offline. To do that, and do it well, you need a way to show the data in different ways even when you can’t call a server.
I often have "What the hell is this thing doing" moments as a web app hangs trying to complete a round trip over my mobile connection when I know it has already fetched the information on that page or I know it could be doing something useful despite not being able to connect.
The author is not proclaiming that SPAs are a bad idea. He's just pointing out how much extra work they are, and that some types of apps are worse as SPAs, or simply much harder with nothing to show for it. He even points out that not all the badness of SPAs is intrinsic to being an SPA:
Why does a website that orders food from restaurants need a Megabyte of javascript?
I tried to figure that out by inspecting the API calls. It turned out they were tracking every mouse event.
In short: 1) horses for courses, and 2) SPA apps are a lot more work and you have to decide when the benefits are meaningful. Less contentious but maybe less fun than trying to argue which is the one to rule them all.
On the other hand, I also maintain a public facing service that is mostly server-rendered with lots of JQuery snippets. I don't see a need to convert it to a SPA. It works well as-is.
I conclude from my experience that public facing services probably shouldn't be SPAs, while things that outgrow spreadsheets might be good candidates for SPAs. I wonder what other areas have been explored.
Saying stuff like this is sure to please the hacker-news hipsters. But... is this honestly anyone's experiencing using new web technologies?
I tend to be on the bleeding edge of tech, and I very rarely regret learning a new technology. And I do not feel like I am wasting all of my time flitting from technology to technology.
I just think this is a smarmy attitude disguised as wisdom. People should like what they like. And as someone who has had to climb that hill before: Waiting around not expecting the world to change around you is a losing bet every time.
The fool doth think he is wise, but the wise man knows himself to be a fool.
> The fool doth think he is wise, but the wise man knows himself to be a fool.
I fear that this wasn't meant to be ironic.
In the past a 'SPAs' was build on top of more solid foundation like smalltalk or later Delphi. Most issues is that the browser stack, put it in real terms, is not the "right tool for the job" and will never will, without serious re-engineering.
People can, and have written bad websites using every technology. I can think of plenty of badly written, hard to use MVC websites from my past.
It should come as no surprise, that bad developers have found ways to make badly written SPAs as well today.
I don't think we should judge a technology by its worst implementations.
If you start with how it's going to end -- it's not going to end well.
Having said that, what you're most likely seeing is that a ton of tools and frameworks are built for no other reason than 1) Coders need something to create to show other coders how awesome they are, and 2) People want something that works like everything they know -- it just does these one or two new things
This is a great way to make a mess over a decade or two, and you're right for waiting it out.
Make a SPA if you need a SPA. Key question: How do I know whether I need a SPA or not? (Or whether React makes sense, etc)
While SPA tooling like React are incomplete since they don't provide all of the client/server data communications that comes for free with a server side application. That is starting to become more "standard" as GraphQL and Apollo start filling the gap of boilerplate. Though of course wrapping your head around GraphQL takes a bit of work for anybody who's spent their life with REST.
Most applications should be SPAs to create the interactions that users expect.
Which is ironic to me. As soon as the teams I've seen start piling a ton of extra stuff into the UI, be it types to make things more safe or logic to make things feel faster, you get a mess.
Note I'm not claiming either of those are the problem. More code is just almost always more mess. Keep it small. If possible, keep it separate.
1) You have the problems that different developers have different styles. So when you jump from one area to another in the code base you're hit with WFT this is functional/procedural/inheritiance/composition, etc. style and your first thought is "barf" they did it wrong...
2) People either have huge functions that are spaghetti or tiny little functions to avoid complexity that are one line if statements.
Both of these are usually rooted in lack of a shared code culture, these are not SPA issues but team issues.
React is about components and you can use React in something like NextJS which is not a single page app but a server rendered pages.
Also, SPA itself is getting outdated concept, now most apps are hybrid of initial bundle followed by a dynamically imported modules. Finally, MVC is a pattern for web pages, the complexity in the client side because what is the being shipped to the browsers are a client side apps with their own router, render functions, state management and APIs.
The modern, offline web is great. If we had to do this in a native app we would never have gotten the project off the ground, because we initially need to use BYOD phones which were evenly split from iOS/Android. We'd have had to use three languages, but a Mac, get developer licenses, and learn Swift and Java just to get an offline frontend, and sharing business logic code would be impossible.
React with well defined static content routing and server-side rendering is amazing at this because the first packets that the server sends the user is html/css jumble.
You can get your app to show text and formatting in as little as 20ms(depending on where you deploy it), then show images, then you don't care if the rest of App and all the js and 3rd party crap take another 2.5s and 3mb to load, The user will do a bit of reading and picture watching, before using a button or input field. However if they're on the go and loose connection, now they have a fully functional back button in their browser to read the next or previous cached html/css content.
We've been "server side rendering" since the inception of the internet.
If you build your pages with CSS at the top and JS at the bottom you're already achieving most of that effect right there, no extra tools needed.
The browser will load the css and content first, and then process the JS requests (Which are easily cachable by the server AND the browser).
I'm currently maintaining alone two large websites and only one of them is an SPA, that's definitely the harder one to maintain by far.
- 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
- result: not so fast initial load (1-2 seconds) but really fast interaction afterwards even on old lowend devices, almost no time spent running js/react/vdom. even some scrolbugs I had to work round before when using react (eg replacing dom nodes but keeping scroll position of a parent container) resolved on their own.
One option is to become a programmer for hire. You keep your skills up, and those skills are as much about getting a job as doing the job. You re-study data structures and algorithms. You can permute sets, find matching subtrees in binary search trees, and answer questions about how addresses in web browsers are resolve to web sites. You learn java, then GWT, then EJB, then spring, then struts, then you add a 2 to the end of struts, then Rails or Django, then you give it all up and do it again in Javascript, React, Vue, Ember. You also play the agile "estimate roulette" as you write down tasks and expected completion times in JIRA, and are asked about deadlines every morning in an almost inevitable corruption of the original methodology[1].
You would never do this for your own project. If you had an exciting new idea, the last thing you would do is go off and learn to find all subsets of a larger set that, when concatenated, form a member or the larger set, at the whiteboard, in 45 minutes. It's also fairly unlikely that you'd set out to write an SPA for many business ideas. But you'd definitely be doing this if you were applying for the next job, which you sort of always are doing, if you're a programmer for money. Even if you aren't looking to change jobs, you still do this, by and large.
Or, you can become the kind of programmer who creates a product, chooses the right tool for the task, and makes it work. The reason that this is difficult is that these jobs are rare. To really have this option, you often need to make the leap into doing your own thing.
That sort of entrepreneurial skill and mind-set seems to be orthogonal to most programmers. I couldn't tell you if it's innate or learned, but I do know that it's a big leap, involves risk, requires a period of economic uncertainty that is tough for people with dependents (or people just trying to pay rent and make it through the next few months in an expensive city). But it may be the best way out of the programmer-for-money quagmire.
The thing is, if you have that kind of entrepreneurial spirit... well I'm not sure you really need to be a programmer at all, there are all kinds of great opportunities out there.
[1] Yes, this is a bad case. Not a worst case, but a pretty bad one. I'd say all programmers for money have gone through some version of this more than once, but I'm putting them all together into something that is more grim than most have to put up with.
A lot of the "modern" toolsets just aren't worth the extra fluff they add.
Writing SPA's in React, Angular, etc. tend to result in a very heavy first page load, then api calls with poor UX for all actions.
Once a SPA is loaded you can send tiny crumbs of data faster than any significant SSR.
You can, but often that's not what's happening.
E.g. crates.io is currently built as an SPA. It is first receiving a HTML page that loads a javscript file, that performs an XHR request (actually, multiple) that answers with JSON that is used to create the final DOM of the page. The Javascript file is cached but that's about it, it still involves one additional needless roundtrip for the website.
The JSON sent is so badly designed that it alone is far more than the final DOM of the page.
Jus check out this: https://crates.io/crates/winapi
vs this: https://crates.rs/crates/winapi
Only the XHR requests for the crates.io page take up 99 KB uncompressed, while the entire crates.rs winapi page takes 103 KB uncompressed.
Because a user doesn't care if it's the initial frontload or not.
Did the company or the end user benefit from this? Hell no. Only one benefiting were the developers who ten left and asked for a 10k more salary on their next job for sporting that fancy new javascript framework. NICE!
I like separation. I know that one side ( ruby, rails, gems, pg, sql etc ) is all about data -> one mindset.
Another side is about views ( js, css, html, multiple select, date pickers, autocompletes etc ) -> different world.
I build my assets in one place, I work with my data in other. I wear one hat as a backend guy, and when I need refocus completely on front end work.
I wouldn't argue it's easier, but I think it's easier for me. I like it better.
Plus, the API will be consumed eventually by user-facing site and apps.
For that latter part, although I must recognize that the tooling has evolved into a quite complex pipeline (which is a cognitive investment, almost a gamble, in itself), I also clearly see the benefits of a set of ideas that have rapidly evolved in the turbocharged settings of the web development ecosystem:
React: the distillation of many programming paradigms (functional, composition over inheritance, etc) for building UI components.
TypeScript: the augmentation of JS with mature and powerful programming constructs.
Material: a visual language for UIs with a strong focus on coherence and being truly cross-platform.
All in all, although I'm well aware of the critiques that can be addressed to the modern webdev environment (the so-called "JS fatigue"), I feel like all these new tools empower me, and I really enjoy learning about them.
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 the Redux dev tools by replaying/modifying the event stream. You can also set up QA folks to export their events so that developers can reproduce any bugs in the global state 100% reliably.
3. Allows you to access global state without explicitly passing down props from great-grandparent to great-grandchild.
While I'm not a fan of using Redux for everything (it does have costs), you mentioned only the most minor benefit. If you only want #3, you would just use React's built in context API.
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.
2. This is only marginally more powerful than a debugger.
3. I would consider this allowing you to shoot yourself in the foot. Explicit is better than implicit, and explicitly defining your dependency tree is a benefit, not a downside. When you're feel the small pain of having to explicitly define a data dependency, that prevents you from introducing it if you don't have to, thereby avoiding the much larger pain of having an overly complex dependency graph. By adding Redux you're adding hours of debugging time on complex global dependencies to save yourself a few seconds worth of keystrokes.
As to other comments about logic in the View or State, it's bound to happen... the two aren't actually divisive concerns. Personally, I'm happier to use Redux than seeing prop drilling everywhere.
I'm not sure why you think the data is irrelevant, or why the component manages it "weirdly".
I'll point out that these top components actually share a lot in common with Redux, except that they can be duplicated and composed with other components, if for example you decide to drop your top component inside of a larger application, and the toplevel components actually don't end up managing data they don't have to (LESS "irrelevant" data than Redux, perhaps?).
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 throughout your app.)
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 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).
With independent components, you do spend some time synchronizing data across components, but each component has the option of how to represent its data internally, so the effects of changing data representation in one area are usually very local, and each area of the code gets to represent the data in a way that's reasonable for what it's doing.
I'll also add that with independent components, you sometimes get components whose only real job is to manage data. That's actually sort of like a Redux! But you can spin up multiples of them without having to manage an array, and compose them or even nest them without issues.
> (Boilerplate, yes, Redux adds that. But at least it's all in one place, and not scattered throughout your app.)
To be clear, I don't really care about boilerplate. It's easy to generate that stuff, but even if you write it by hand it's faster than debugging implicit, hidden complexity. Boilerplate ISN'T the problem with Redux, as far as I'm concerned.
If you keep your state in a component, you don't need any housekeeping, once the component is gone, the state is gone.
This is not true with Redux. You have to keep remembering to clean the state after you're done with something or you're going to introduce a bunch of bugs.
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.
Many people just use setState.
Since my last Redux project in 2015, I did many React and React-Native projects and not one of them used Redux.
If you don't use redux, then keeping state synced with a server side rendered application because nearly impossible.
Could you explain what you mean by "server side rendering state"?
Fair point. But could it be possible that there are lots of people doing React that never went to college and never wrote Python or C programs?
Not that react isn't great for traditional websites, I've just seen too many fullstack or backend devs struggle with it, so if they're going to be involved in the frontend it may be worth considering the alternatives.
The updates are handled by JavaScript and http calls.
You can write a lot of that stuff in a dozen lines of JQuery with nicely refreshing content and ajax instead of throwing in large amounts of framework bloat.
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.
It's fetching and replacing the HTML that needs to be changed, but removes the need to do a full-page reload, so the browser doesn't have to re-load and re-parse all of the HTML, and JS, and CSS. Even though the browser will keep a lot of this stuff cached, Turbolinks can make a site feel a lot faster from a user's perspective. But regardless, it's more than just a loading bar at the top of the screen.
Whether it's the right fit or not depends a lot on what you're trying to do.
That's only 1-2 seconds on a fast connection.
If you have zero of that content cached locally and are on a mobile or just not-fast connection it'll be way more than 1-2 seconds.
Your "solution" is one of the ones responsible for locking up mobile browsers all over the place, because the browser still has to deal with the entire DOM, and it's often done way inefficiently.
nothing else because all images are already inlined as svg as well as all styles and the mentioned js code
> Your "solution" is one of the ones responsible for locking up mobile browsers all over the place, because the browser still has to deal with the entire DOM, and it's often done way inefficiently.
I only came up with doing it this way after previously having build the same app using react and old devices (eg android pre chrome) could not handle all the vdom diffing and add/removeNode.
Our users preferred a slightly longer initial load (even 10 seconds) and lightning fast interactions afterwards over fast initial load and sluggish UI for all the time using the app.
When doing client sit rendering you would still have to transfer and parse little chunks of json all the time.
As it turns out browsers are really good at handling even huges DOMs as long as you do not manipulate it to much.
Granted this way only works if you have a limited set of states/pages (eg a few thousand).
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.
Overall it loads in right around 1s, as I mentioned the splitting for async load on demand doesn't work at the moment, which I had the initial load for a page not using chart.js down to around 115kb gzipped. Part of that also includes the embedded SVG icons as well as the JSS for styling.
It's not paying attention when lodash + underscore, + rambda + momentjs, etc. all get loaded via dependencies... most of that can expressly be avoided with specific smaller frameworks and tooling.
There are some languages that are so “powerful”, “flexible”, and unopinionated that every developer has dramatically different coding styles (JavaScript, Scala, etc.). On the other end of the spectrum are tightly prescriptive, constrained languages where everyone’s code looks the same (Go comes to mind).
No doubt team culture plays a part as well, but in team settings it is important to pick tools that are designed for team settings. These tend to prioritize regularity, lack of flexibility, syntactic simplicity, static analysis, etc.
I know the world is sick of gardening metaphors, but I do feel like there are lessons from community gardens. (Really any community thing.) You will usually have an owner that will paint broad strokes of what the rules are. Then, a bunch of spots that contributors are touching regularly. In their contributions, the rules are much more free form. But, you don't typically have people moving rapidly between contribution zones.
Which gets me to my favorite take on the answer. Solving the customer problem is not necessarily the same as solving any developer problem. If you are lucky, you can align them. However, as a developer brutal honest with self in "did this change actually provide any value to the customer" has to be constantly asked.
There's nothing new or especially special about "server side rendering", and nothing about React rendering either.
Rendering on the server lets you do whatever you want.
Want to put the user in a specific state? Sure, go for it.
Want to use a starter or null-state? Sure, go for it.
https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
I only did green-field projects where I was the only front-end dev.
A lot of what clojure does, Typescript does it really well with it’s types in jsdocs.
I'm not sure what the term for it is, monolith maybe.
Also, it's hard to realize how much work a SPA actually entails until you get your hands dirty. SPAs generally sound great on paper from a technical standpoint.
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!
Nothing can possibli go wrong
I have to ask... what went so wrong? If you had a time machine, what would you tell your younger self?
It was a mistake because we needed to move fast and figure out if we had something or not. A simple CRUD website (say Ruby on Rails, Elixir/Phoenix, or even straight up Node/Express) would have been faster to build and iterate on.
There was one section of it that would benefit from being able to work while offline, so that could perhaps have been built as a small SPA. But the rest, that was in hindsight a mistake.
https://www.embarcadero.com/products/delphi
(it have a free edition) and alzo exist Lazarus, a open source clone:
Is probably the most fleshed idea under more "traditional" paradigms (OOP, RAD, etc)
Smalltalk and others are less popular(?) and only know them passing, so can't give too much of that.
---
Another interesting stuff can be rebel/red:
much low-level but nice way to do UIs in a apparent declarative way..
though that doesn't negate the point of SPA which enables building clients that run directly on the users devices and are not hampered by the difficulty of emulating stateful clients on a server.
i am not trying to diss backend frameworks here as bad. any of these would be a good choice for the backend.
the point is that thanks to SPA and CRUD i get to reuse that same backend over and over with little or no modification. (modifications amount to fixing bugs and very rarely adding new features to the API)
my backend development time now is effectively 0!
[0] (i have been working with laravel, django and others (primarily roxen and pike) before, and while i am not a fan of php, i did find laravel pleasant to work with)
Facebook is probably the least clear one, since they put great effort into eliminating discoverability and accessibility from "outside", i.e. without a Facebook account. They're basically the AOL of today, which was a classic application back then that tried to contain a proprietary "web" of stuff in itself, only accessible if you ran their "browser" application, had an account with them and were logged in, and that "AOL Internet" of course had its own search mechanisms, just like Facebook has its own sophisticated search. However, they're not fully closed-up, they just try really hard to nag you into having an account, which is why I'm inclined to still put them in the "website" camp.
However, all of these web sites surely contain certain parts that are in itself "web apps" and that are pretty much isolated from the basic parts of the site (albeit possibly interacting with it at well-defined points through APIs). I guess that this is a logical result of the large engineering teams that are working constantly on what is basically the same big website - at some point, in order to scale out further, it just becomes economic and practical to effectively isolate certain features into mostly separated "apps".
I run a somewhat popular media site implemented as an endless-scrolling SPA. Clicking on an image or video opens its detail page in a floating modal and changes the URL. I specifically wanted people to be able to link to content this way, and my SPA will load that modal and the media-gallery behind it.
Quickly, SPA just becomes implementation detail. It's the level of user-interaction that dictates your implementation. For example, if you insist on your site being server-rendered with heavy Javascript that takes over, there may be a point where it would've been simpler for you to just implement it all in Javascript (the SPA).
I could've implemented my media site without Javascript. Or maybe just with AJAX that returns HTML. But I know from experience that, while simple upfront, those become more complicated as you try to build more interactive UX and starting wishing your Javascript had more access to the context. At which point a SPA is just another tool for managing client complexity in some other quadrant of the graph. But there's some nuance to the question of whether your site is or should also be in that quadrant.
A more interactive Javascript-heavy UI can improve a lot of aspects of even websites we consider to be a server-side-rendered gold standard like a forum or message board.
For example, look at the right-sidebar scrubber on Flarum that lets you quickly scroll to arbitrary parts of a long forum thread: https://discuss.flarum.org/d/17745-flarum-0-1-0-beta-8-relea...
Or look at how clicking a submission on Reddit's new UI opens it in a floating modal window so that you don't lose track of where you are when you click out of it. It makes opening submissions feel cheaper/faster to me where, in the old UI, I tended to open everything up in a new tab.
There's a more thoughtful consideration that needs to be had here than just "webapp or website?" Else you're back to cargo-culting.
The first could be done easily with anchor links - if the content wasn't loaded dynamically.
And browsers are perfectly able to return you to the same position in the page - unless it's all loaded dynamically.
https://www.talkyard.io/-32/how-hacker-news-can-be-improved-...
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.
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 navigates through your website.
Here's an example with Create React App: https://github.com/cereallarceny/cra-ssr
Gonna have to quantify that. Cause I imagine if you did, you'd redact that statement. Redux is a very straightforwards and SMALL library that handles global state.
Its concept can be difficult to follow at first which may cause some to think it way more complex under the hood than it really is.
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.
I believe the GP meant "unrelated". Can you drop your top level component into another application with different children and still have it work? Can you move the child components to another view tree and still have them work? It seems like what you are describing is a top level component that is tightly coupled to its descendants with too many responsibilities. In the ideal react app architecture you should be able to take any component and move it anywhere else in the app and it should Just Work. This is the problem redux is supposed to solve, and I would argue that by enforcing an explicit pattern that most experienced react developers know, you will get closer to that ideal than if you have a variety of home grown solutions that vary from project to project (and even from developer to developer on the same project). "The Tyranny of Structurelessness" etc etc.
Yes, it's a matter of passing the child into the parent as a prop.
> Can you move the child components to another view tree and still have them work?
Yes, this sort of thing is exactly what you get for free by doing things the way I describe.
> In the ideal react app architecture you should be able to take any component and move it anywhere else in the app and it should Just Work.
This is exactly not what happens in Redux projects in my experience.
Sorry to beat this dead horse, but how does redux, which binds data directly at the level of the component that displays the data, make portable components more difficult than vanilla react where stateful components and functional components are tightly coupled? Do you have links to a gist or something so I can see what you're describing?
Just build a normal website and let my browser do what it was built to do. The APIs that allow SPAs are great and useful. The Pixlr online photo editor has a good reason to be a SPA, and that works great for it. Your forum/email interface/management API would work better as a normal website.
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.
All that information exists only once and is needed in many parts.
I think these debates about global variables or state could be much more specific, though.
For example, we tend to realize that letting any component access a `require('./store').currentUser` singleton may make testing harder, but this global dependency still exists when, say, it's distributed to all components through the React context. I reckon most people are thinking of the singleton example when they lambast Redux but it certainly doesn't have to be that way.
OTOH jquery is much bigger than you'd expect, there isn't much of a difference between a minimized jquery and vue, or even react once you factored in gzip.
And while I've no experience doing so using vue, writing small dynamic react components embedded in larger static HTML pages is quite enjoyable.
When you have 2mb worth of "React code" and the framework itself only takes up 35.6kb, that's a lot of bloat.
And if the project isn't worrying about bundle size at all, then even their vanilla/jquery page is going to end up bloating a ton as well.
More often than not the culprit in 2mb bundle sizes is a a few packages that include "data" in the bundle (For example, i've seen timezone and locale information bloat bundles by megabytes, and in one case a 5mb bundle ended up being 4.6mb of zip codes...)
Even ignoring that, React app sizes are getting better. Modern React apps (basically since 16.7) that are written with things like Suspense, lazy, and hooks are usually pretty small. Writing functional components and composing your app pushes you to write less code. Plus React gets things like code splitting for free with webpack if you use lazy, so the first page load only downloads things that are actually needed to get to interactive.
No doubt some less considerate developers will still manage to write giant apps that take ages to get started, but they don't have to. Bloated apps are a function of developer's choices rather than React (or any other JS framework) forcing the apps to be bloated.
> 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.
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 actually exacerbates the issue because it separates the data from the components that use it, making static analysis tools unable to see how your data changes might break the components. This also goes to show you didn't even understand the part of what I said that you selectively quoted, since I already said this.
> I'm not even hesitating before I choose the first option.
Perhaps if you hesitated a bit more, you could use that time to read all of the options and understand them.
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...
> Futher, Redux doesn't solve synchronization issues in situations where you can't represent the data the same way.
It's kind of the whole Redux philosophy that you won't do that. It's in the FAQ. There's no "can't". You're never forced to keep duplicate data in your store.
I'm not saying there aren't solutions to the problems I'm bringing up. I'm saying you don't have to solve them in the first place if you don't bring in Redux.
You keep saying that you won't have these problems if you don't use redux, but I am arguing that _you do have these problems_, you're just creating ad-hoc solutions for everything that you would use redux for, except those solutions are sprinkled into your UI components in a way that makes them full of mutable state that is impossible to test and a constant source of bugs. Note that I have already agreed that there is a scale where redux is overkill and creates more problems than it solves. Once your app has a few dozen components it's time to start thinking about another layer of abstraction.
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 are not enough for large projects, you also need a way to manage side-effects. Incorporating `redux-saga` would fit that purpose.
React, redux, redux-saga -> this is the recipe for large scale applications that I have used, built, and helped maintain with success.
One of the strongest benefits of redux is being able to see every single event in a debugger that displays current state, action payload, next state. It really does make tracking down state changes a matter of reading a global log.
Furthermore, because redux is not dependent on react and under the hood it is simply and event emitter, it becomes relatively easy to use the same exact business logic for one web app and use it for some other delivery.
We did this at my last company: because our business logic was based on redux and completely separate from the UI layer: we were able to build: a cli, chrome extension, outlook plugin, and mobile apps using the same exact business logic.
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 large projects, you also need a way to manage side-effects. Incorporating `redux-saga` would fit that purpose.
I don't need a way to manage side-effects, if I don't use Redux...
I'll admit I haven't used Redux-Saga, but you'll excuse me being skeptical that introducing more complex tools will solve my complexity problem.
> We did this at my last company: because our business logic was based on redux and completely separate from the UI layer: we were able to build: a cli, chrome extension, outlook plugin, and mobile apps using the same exact business logic.
Again, this is not unique to Redux. It's perfectly possible to have your business logic completely separate from the UI layer without Redux. In fact, my experience is that Redux tends to cause devs to mix UI logic into business logic (and any sufficiently complex UI will have its own state and logic separate from the business logic).
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.
So far every way of doing UI I have seen isn't maintainable long term. Yet somehow things wind up being maintained even if it is in that "why me?" kind of way.
I think this says less about frameworks/libraries themselves and more about the amount and sources of entropy present in the front-end. That's really what we're dealing with here.
Libraries/tools/patterns/frameworks all usually have the function of containing some of that entropy. In theory the best tool contains the most entropy while allowing you to produce results you can sell to all stakeholders.
I think over the years we are doing better and better, but it's a long game. We're not all the way there yet, is it even possible to get all the way to the dream?
Which is why a lot of people that encourage Redux tend to also encourage one or more of the "side effect" managers such as thunks, sagas, or observables (my preference).
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 oreo" gluing React to all my interesting "epics" describing high level functionality in the applications.
It's also the Unix philosophy thing of use tools that "do one thing well" and then chain them together. React does view components rather well, Redux does state management rather well, Redux-Observable does state "interaction" rather well. Chained together they work remarkably well.
When I hear someone complaining about redux using global state, I like to ask them what makes global state bad. The answer is usually that it allows any part of the application to change a value, which makes debugging difficult. This doesn't apply to redux and similar frameworks because every slice of the state can only be managed by a single, pure function, which makes it incredibly easy to debug. Additionally, redux uses a copy on write mechanism, so your state tree isn't actually being mutated, which allows you to use equality comparison instead of a deep compare to see what state has changed. That, combined with the fact that all actions go through a central dispatcher that is easily audited means unit testing your state transitions is almost laughably trivial. And since you are pulling all of your business logic out of your UI components, you can avoid the side-effect hell of unit testing your UI.
Having said that, I won't use react or redux for any website that doesn't have a heavily interactive UI with complex state that must be shared across many pages. Managing application state in your front end is an enormous burden and you'd be crazy to take it on without a need for it.
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.
Good for you with your fast, always-on internet, I guess. Some consumers have to deal with expensive and unreliable 3G internet (that downgrades to 2G occasionally) - an offline-capable email (or management) SPA is indispensable for them. Sure, you could write 4 native offline apps for MacOS, Windows, iOS and Android but that is a bigger investment than targeting browser standards.
And then you're right back to any component that uses User being tightly coupled to the structure of the User, without any of the syntactic cues that allow you and your static tooling to connect the two.
> except those solutions are sprinkled into your UI components in a way that makes them full of mutable state that is impossible to test and a constant source of bugs.
That's not the case:
1. There's nothing preventing you from treating components as a pure function of their props.
2. At the top level, it's necessary to have some mutable state, but I'm not sure where you get the idea that this isn't testable. Redux doesn't remove mutable state: all redux is doing is a big complicated version of newState = pureFunction(oldState) which is perfectly possible to do using Vanilla JS functions.
The PoC ended up working out, and we built the infra to correctly handle the lookups without needing to bundle the entire country from there, but man did that raise some eyebrows from a few other devs that noticed it!
Restrictions are the price of solving hard problems (even if you don't want to admit they're hard) in a deterministic fashion.
Come on, 16.7 was released in December and 16.8, with stable Hooks, was last week! It's interesting that React has added these features and it bodes well for the future but you can't claim capabilities that have only existed for the a few months is what constitutes "modern." React's pace of adoption has been remarkable but that also means there's a lot of code that already exists that isn't going to be changed right away to take advantage of these features.
So like, a month ago?
If it isn't less than a month old, it's "the old way" :)
FWIW, we've got a new Redux Starter kit package that tries to be a bit more "batteries included". It includes utilities that help simplify several common use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state automatically. It also includes `redux-thunk` built in, as well as some middleware that check for things like mutations.
Please try it out and let us know what you think!
I understand why folks have opted to create higher-level frameworks around Redux like Rematch, and it's not "wrong" that they've done so. But, looking at Rematch code, you can't really tell that it's actually Redux underneath.
With RSK, I've aimed for an intermediate level - decreasing the amount of things you have to write by hand and the literal number of keystrokes you have to type, but preserving the idea of "dispatching actions" and using reducers.
Glad to hear that you think it looks good! If you've got any additional feedback or suggestions, please let me know.
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?
First question (show user data in nav bar, user details page, and "comment thread"):
User profile page is obviously showing full user details, so you're going to want to have a separate endpoint for "getUserDetailsByUserId(int userId)" or however you want to name it.
What data are you showing in your nav bar? Is this just a user-avatar image link/button? You would rarely want to display anything other than an avatar and/or username in a navigation bar. You could maybe talk about a navigation drawer instead, where you have more simple details like maybe email address and phone number or something.
What about the "comment thread"? Are you showing anything more than an avatar and/or username? This sounds like the same use-case as the nav bar... how would the display differ here?
If you have use-cases for anything more than your basic "user avatar" and "full user profile," (and maaaybe "user basic info," for a "nav drawer" or something, although those are being phased out of most current design standards) then I would seriously urge you to re-think your app design. That polish of showing the user info in a slightly different slice on some specific page is almost never going to pay off for your company, imo.
Anyways, if you want to be naive about all of this, you just save the userId (and token or whatever, but that should be in your http middleware) after a new login session, and then you request separate "getUserNavBarInfo(userId)", "getUserDetails(userId)", and "getUserCommentInfo(userId)" and load the results of those into your UI views on-demand. If you need to progressively tune/cache your API, you do this separately based on usage stats for each of these 3 use-cases, you don't start with directly caching "Users" and adding the business logic client-side to translate into the 3 use-cases.
If you want to do a more thorough dependency-injection "user component," then this might vary depending on your DI framework, but the high-level idea would always just be to create a user module with all the info needed for a given user, wire it up to reload the module in your DI graph on new login and on-success of any request to update user info. You could have both your "login" and "update user" endpoints both return the full set of data needed for the "user module" on success. Then you need to set up your DI injection component scoping so that your user info injection component is dumped on user logout and settings change, and is recreated to do it's injections with the new/updated user module each time. A singleton DI "user component" that you must choose to inject into any UI component that wants to show user information seems much more constrained in complexity to me than just having the ability to arbitrarily pull out various bits of user info from a global redux state, at any place in your app.
Second question (single source of truth, increases or decreases complexity?):
I think this question is orthogonal to the capabilities Redux (and similar) provides. Redux has nothing to do with outright increases or decreases in app complexity, it is simply a tool that enables various (opinionated) architecture patterns. If you have a separate, domain-specific, well-defined event+data architecture that you are sticking to very strictly to keep a handle on complexity, then Redux can (imo) reduce boilerplate and allow very elegant interactions between various data/biz logic/UI components of your application, all without any "tight coupling". It's really just a message-bus pattern at some level. This sort of thing has been around longer than the concept of software itself, there are hardware components literally called "buses" that basically do the exact same thing (ship events and data around to various interested parties without requiring a direct circuit connection). The danger is that it opens up a TON of pathways to insane complexity and totally unintuitive event & data flows, because it kind of allows you to arbitrarily add "side effects" to basically anything in your application. VERY easy to foot-gun yourself here if you start getting lazy and just wiring up random shit instead of following strict event/data patterns and keeping the "feature code" as simple as possible (e.g. with a strict facade for writing new pages).
This might rustle some feathers on here, but I wish people would think of React/Redux sort of as "framework primitives" that are SUPER useful for constructing your own domain-specific client-app frameworks, but somewhat dangerous to open up directly to front-line product code written by junior devs. I would much rather see a few senior devs use React/Redux to construct a tightly-defined domain framework that exposes a simple facade to junior devs to construct new pages/routes/behaviors in your FE application. I think using these tools like this would greatly reduce the dreaded "React learning curve" of 3-4 months that everyone talks about. That could be done over time if you put in the work up front to build an internal facade pattern around your core React/Redux app architecture. Then junior devs could choose to dig into things behind the scenes as they go, instead of being forced to front-load the entire React/Redux knowledge stack up front right when they walk in the door.
Also, "state" does not necessarily imply "mutable". (Redux encourages an immutable state approach where good reducers don't mutate state in place, but instead build new state from old, though Redux is not strict in enforcing this best practice. For Redux the "current state" is "file handle" that simply updates from one object to the next, not all that different from stdin/stdout/stderr or even somewhat to static configuration that is somewhat updateable without restarting the application.)
> Also, "state" does not necessarily imply "mutable".
Okay, sure. I'd rather not get into a semantic argument about the meaning of the word "state". Suffice it to say that I'm talking about mutable global state.
I respectfully disagree here. All UI views in React can be controlled via parameters. Very few components in a React application require state management. You can add parameter functions to handle various events as well.
> which allows you to use equality comparison instead of a deep compare to see what state has changed
You are doing a lot of deep compares on state in a real world application? Why? If you only use parameters for the state of your component, everything is already handled by React out of the box.
> every slice of the state can only be managed by a single, pure function
Really? You can trigger reducers from literally anywhere in your application. Not only that, you can create multiple reducers to handle each action type. I've seen a situation with 24(yup, 24) reducer functions for a single action type. Many of those reducers contained complex business logic checking the overall state of the application. Then you have 2 or 3 action functions all with different business logic for that one type. Race conditions everywhere. setTimeout 0, here we go again. Step debugger hell. Of course, you should never do this, but in the real world, this is what happens over and over again.
> means unit testing your state transitions is almost laughably trivial
If you use parameters for state of a component it is 1,000 times easier. Because a component's view is not coupled to the global state of your application. Pass it parameters, test that it looks correct. Change a parameter, check if it is correct. Dead simple. Your tests are not bound to global state at all. Again, you started with an anti-pattern of managing state in child components, and now, instead of not doing the anti-pattern, you are adding yet another tool to fix it. Instead of just not doing it.
In summary, what you are describing is the "theory" of why Redux and associated tools should work. In every case that I've seen(10+ at this point) that has not happened. Not because Redux is a bad tool. Its not. But in the real world, it has become incredibly expensive for many organizations to maintain.
I agree. My apps usually consist of a few stateful components for dropdowns and modals and such with the remaining being functional components. The problem is the majority of "legacy" react apps I've come across seem to have the opposite ratio (I personally think this is because most react tutorials are written for fresh out of bootcamp developers by slightly more experienced fresh out of bootcamp developers).
> You are doing a lot of deep compares on state in a real world application?
Not a lot, but when you need it you really need it (usually for shouldComponentUpdate, but most recently I needed it for synchronizing state to localStorage).
> I've seen a situation with 24(yup, 24) reducer functions for a single action type.
You're right, that is insane. I personally use thunks or sagas to dispatch multiple actions that are specific to the domain model being updated and never update multiple slices of the state tree with a single action. For example, the action dispatched by clicking the sign in button should not update the user profile and the navigation state. Again, the problem in your example is not redux, it's a lack of separation of concerns.
> Become a components view is not coupled to the global state of your application.
The state of your application has to go somewhere, and if you are creating a small amount of stateful components and a lot of functional components, you are doing a lot of prop drilling, and every time the stateful component is updated the entire component tree gets re-rendered. If you keep the stateful components at the minimum height necessary, your business logic will be split up according to where it needs to be used instead of logically grouped by feature.
> summary, what you are describing is the "theory" of why Redux and associated tools should work.
You are arguing that redux is a poor choice because bad developers write bad code. I'm saying that the constraints that redux imposes on the structure of your code makes it easier to enforce separation of concerns as the app scales in complexity. The things about redux that most people complain about are the things that make it work so well in complex applications. I have seen unmaintainable apps that used redux, and equally unmaintainable apps that used component state. I don't think anyone can accurately say that one is worse than the other in a pathological case. At this point we're just arguing about opinions, but I maintain that explicit structure using shared conventions is still better than ad-hoc structure that requires institutional knowledge to navigate, even in the hands of untrained code monkeys.
One thing I have noticed is that every time react or redux comes up on HN it starts a flame war with the same arguments rehashed over and over, and when I get involved in these discussions none of my comments ever get any up or downvotes, which tells me that nobody is reading this and we should get back to work. :)
If there some kind of state that doesn't neatly fit into these solutions? I know that passing around signed-in user objects is one popular use case for Redux, but in my opinion that could be easily placed into localStorage, or assigned to a window.global_state variable.
I liked it more than redux, because you can have have simple class implementation and side effects without much hassle. Also TS support and testing is easy.
(Which is an interesting turn of events, personally, because I really liked Knockout ages ago, but its attempted successors in MobX, Aurelia, and even Vue leave me cold. I think partly because Knockout was so much more verbose and forced/needed a clearer "MVVM" separation simply by how "dumb" it was, whereas Proxies and Descriptors gives too much of an illusion that you are working with "plain" objects that don't need a clear "MVVM" separation until it is sometimes too late to fix a maintainability/tech debt hole.)
Sure, you don't need Redux in the middle of the "oreo", but it's also not the "wrong" answer, either.
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.
> It's also the Unix philosophy thing of use tools that "do one thing well" and then chain them together. React does view components rather well, Redux does state management rather well, Redux-Observable does state "interaction" rather well. Chained together they work remarkably well.
Don't sully UNIX philosophy by comparing it to Redux! UNIX is such a different environment from JS space that it's hard to really even compare the two, but 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.
[1] https://www.amazon.com/Design-Patterns-Object-Oriented-Addis...
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.
Reacting to object changes (persisting them to a database, or otherwise audit logging them).
Kicking off and managing "background tasks" like chron-job equivalents (5 minutes after a state update do some other related thing, such as a automatic state machine transitions), database synchronization/replication processes, cross-checking/merging in data from GPS/geolocation/compass streams, etc.
This is a huge pain in the ass and requires a ton of really tricky UX design. What happens when the data is cached and you fetch it again? Do you disable the UI and show a spinner until the request is complete (why bother caching the data in the first place)? Do you allow the user to continue making changes while the request is pending and try to reconcile conflicts when the payload is parsed (this problem is far beyond the skill level of most developers)? When the data is loaded, do you just change the content out from under the user or do you write a series of complex animated transitions to make it less jarring?
Updating state on every transition is hard, and keeping two copies of the data is also hard (cache invalidation!), which is why you shouldn't use an SPA framework unless you absolutely require it.
> If there some kind of state that doesn't neatly fit into these solutions?
The type of state is completely orthogonal to whether redux solves more problems than it creates. It should not be included by default on every project, and there are thousands of alternatives that might be a better fit. The heuristic for whether you should reach for something like redux is the size and complexity of your app, not the type of data you have. If your app consists of a single route without a lot of branches in your view tree and most of your components are only used once, you definitely don't need a state management library. Once you start adding multiple pages and lots of component reuse, something like redux starts to increase structure and maintainability at the cost of additional complexity. There is also a lot to be said for using an architecture that most of the react community is already familiar with so new developers can ramp up quickly.
> Persisted to localStorage
This is a standard practice, but you have to be careful not to spam localStorage with updates since it's significantly more expensive than in-memory object creation. I haven't profiled it but I wouldn't be surprised if it were several orders of magnitude slower. I sync the application state to localStorage in all of my apps, but I debounce it by 500ms and use equality comparison to prevent writes when no changes have been made. Obviously none of this has anything to do with redux, but redux's copy on write mechanism makes comparing states trivial, and any code that mutates the state trees requires an expensive and tricky deep comparison that negates the benefit of making the comparison in the first place (especially in the case of shouldComponentUpdate).
> assigned to a window.global_state variable
This is not the same as globally available redux state. For one, redux does all of the plumbing for subscribing to state changes and preventing unnecessary re-renders. You could spend a couple of days writing your own, buggier implementation, but why would you? Secondly, as I've argued elsewhere in the comments, the redux state tree doesn't have the aspects of global variables that make them such a dangerous anti-pattern. Writes are isolated to a single function, and all other references are read only, and it uses a synchronous message passing system with a central dispatcher that is trivial to audit. Another commenter complained about race conditions, but redux core is only designed to support synchronous operations, and there are well tested and widely used tools for managing complex, multi-step asynchronous state updates. If you have race conditions you are using the wrong tool for the job.
This is a bit off the topic of your original questions, but every time one of these redux conversations comes up there is so much vitriol from people who just absolutely hate redux for some reason, and almost every time every reason they give for why redux is a cancer is a well known anti-pattern. I guess they tried redux, hated the verbosity and saw botched implementations by other developers unfamiliar with redux, and decided that redux was the problem instead of lack of experience.
"The framework has to be idiot proof" doesn't really hold water for me, since I would love to see a react stack that scales in complexity to hundreds of components and dozens of routes that isn't horribly complex and deadly in the wrong hands. The root cause is that react is a view library, not a framework, and there is no standard architecture to provide a common language between teams and developers. Since every project is unique there is no knowledge base of best practices that aggregates over years like rails or django or laravel. A massively complex SPA _absolutely requires_ a strong, experienced lead to enforce good practices and maintainable architecture. If you have a free for all with a bunch of junior and mid-level devs you are going to get a pile of crap no matter what stack you use.
I am not a zealous redux partisan, I just prefer to work with it because I know it well and I believe it uses a pattern that scales well by keeping business logic isolated and broken up into small pieces. I'd be perfectly happy to recommend something like mobX. The only thing I'm strongly against is mixing application state with view state. Anyway, I've spent several hours and put a lot of thought into responding to questions on this thread and some of the comments have been pretty rude, frankly (not yours). I would like it if people could discuss this topic politely and constructively, and not go into it with their mind already made up and ready to do battle with anyone that disagrees with them.
Rant over :)
So like I said, I've basically decided that Redux would be a great benefit for maintaining a consistent, easily debugged architecture for an app of this complexity, but then I came across several people talking about shared global state across routes as a good heuristic for knowing when Redux is appropriate. As mentioned, I don't really have that in my own app, so I was a bit confused by this and wanted to get some more details from you. I think you've cleared it up pretty well.
I'm completely in agreement with you about the likely source of dislike and complaining for Redux. Absolutely people jump to it too often when it isn't necessary. More generally speaking, I think there's a default attitude that front-end should be easy, and then people are rudely surprised when they find out that it's actually very hard. Distributed systems problems, cache invalidation problems, combinatorial scaling of complexity with every feature and source of user interaction... you already know this. They blame the team or the tool, but there's a fundamental complexity there that's unavoidable and deserves respect.
Anyway, thanks again, I've enjoyed reading your opinions on this.
This sums it up so succinctly I'm going to borrow this next time I'm discussing react with one of my C# teammates. :)
If you want to chat more my email address is in my profile.
