Things I wish I knew about state management when I started writing React apps

I just use vanilla JS. For transport I use JSON over Websockets (with fallback to long-polling if the user is behind a proxy that doesn't support Websockets). I format the messages like id+command+json-payload. If the message contains an id, it calls the callback function given by the API request. If no id is given, the event listeners for "command" are called. In a higher level there are more events that can be listened for.

For layout I use a mix of both pure and imperative functions that either creates a new element for every state, or modifies existing elements - however all isolated in a component or widget.

I try to use standard HTML5 elements rather then creating my own. But they are often inside a component or widgets which takes care of events like keypress, mousedown etc.

There are no string templates! No server rendering, just API endpoints. There is no JQery, there is no framework - besides the functionality for handling server messages and passing data to event listeners and callbacks. Some components and widgets are generic and can be reused in other projects. But most are specific to the app itself.

The advantages is that it's simple, fast, and customizable. The disadvantage is that layout is a bit tedious using appendChild instead of XML/JSX.

I use CSS for styling. I like CSS very much probably because I used to do web apps before CSS existed. To change theme you just change the .css file. Components, widgets and elements are not aware of theme and style, that's all handled by CSS. Animations are handled by CSS, and different screen sizes are also handled by CSS. Sometimes you need to the change components/widgets though.

The only advantage I see with frameworks is that you get to write XML/JSX/HTML, which makes it more easy to move things around vs just using JS functions and appendChild. But when looking at React apps the components are broken down into individual files anyway, so it's difficult to get an overview.

Probably the biggest advantages of going vanilla JS eg. no JSX nor frameworks, is that debugging becomes easier, and you do not need a build pipeline, just refresh or hot-reload individual functions. No bundles or package managers needed.

> A framework that has no community support, no stackoverflow articles to help out and most likely minimal explicit documentation.

But there are gains too. The custom framework is probably much smaller and less complex, easier to know 100% of. It can be stepped through in the debugger. It's much easier to change and add features that your company needs, there's no outside bureaucracy to get in the way.

I disagree you're inventing your own framework too, there is a distinction to be made between libraries and frameworks. Just because I'm not using a framework doesn't mean I'm reinventing it, I could be using something like knockoutjs instead, or even postbacks.

- Using a UI framework maps well to working with UX designers in that you design the interactions of a given component in accordance to UX spec.

- Combining multiple components in a given page to transform or process user interaction becomes simpler as the components are plug and play with the state of the page.

- Combining multiple pages where state can move across an entire application can allow for a seamless user interface

- Employing techniques like code splitting and Server Side Rendering allows for smaller js payloads with an incremental approach to assets versus loading everything at once.

The largest advantage UI frameworks provide is that it makes what you would normally do with javascript a lot more _composable_. You can do the same with vanilla JS, but it gets a lot more difficult when you attach events to the DOM, it's hard to reason about how you might organize your code which doesn't scale well across teams.

I think the simplest way to consider the advantages of a UI framework is to build a search application from scratch with vanilla JS. You can get pretty far but once you start adding in things like pagination, it can get a little hairy. jQuery and it's libraries can help you there, but there's a good chance that you're adding in some overhead to the load times of your page.

If you rebuild the application with a UI framework and employ practices like code splitting, the code (usually) ends up being a lot more reasonable and easy to extend (which businesses tend to like). Adding features becomes less about reasoning about which DOM event fires what and instead more about transformations in state with the components subscribing to state instead of DOM events.

I'll counter this by saying making forums is my least favorite thing to do in React.

Doing it by hand involves a ton of repetitive work.

Each form input needs to have its input validated client side (immediate errors), needs to have error messages from server side validation, needs to be accessible, needs to work across all browsers, any sort of drop downs from an input need to have proper a z-index, and state, so much state to track.

Doing it in vanilla Redux just sucks, and it is super easy to completely kill performance. Behold the number is sites that have a non-trivial delay when typing individual characters into a form.

(I've seen input delays on sites approach 500ms per character!)

(Of course 90% of this goes away by letting the browser handle forms, and accepting page refresh on submit, but if you want to go SPA...)

One of my larger regrets from my last project is not just learning a form library, it would've saved me literally weeks of work.

Although that entire site is a worst case, it is 3 giant forms each with over a dozens inputs varying from plain text to numeric to date-time to an image uploader and gallery manager.

Basically the best case scenario for "I should've learned a 3rd party library".

Why is state management such a talked-about issue with React? Other than distributed state, which obviously comes with its own set of challenges, managing state doesn't seem to be an issue with any other language, framework or platform. But with React, it seems to be a major part of the learning curve, with entire tutorials dedicated to it and numerous libraries to help with it in some way.