> React is not just a view rendering library anymore<p>I was felling like this too, but I found my balance using the Controller pattern, I only use hooks in controllers, and dispatch from controllers only, then I do not have logic in controllers, but I added some concepts of DDD having all the business logic separated, to the point I could change the whole ui framework (let's say material-ui by fluent-ui) and it wouldn't affect any controller, business logic or application types.<p>So with Typescript + Controller pattern + DDD concepts I'm quite happy with the separation of concerns.<p>This is how a route looks with Controller pattern.<p><pre><code> <Route exact path="/:username">
<SignedInLayout backgroundType="paper">
<ProfilePageController>
{(props: ProfilePageProps) => (
<ProfilePage {...props} />
)}
</ProfilePageController>
</SignedInLayout>
</Route></code></pre>
> The syntax<p>I disagree. My team has written a medium size web app ( ~30 pages) without JSX and the API works pretty well. You get used to it if the whole project uses it (just like any API).<p>> create-react-app<p>I disagree. It is clearly intended as a quick start, people can customize or opt out in one command (and remove whatever they want).<p>It is very functional and engineers get a production ready layout and build system in < 1 minute.<p>It doesn't force you to use it, use it if you want.<p>--<p>Finally your example doesn't look much better or clearer than using the React API directly..
It's hard to take this seriously. Saying React is bloated because `create-react-app` pulls too many dependencies makes it seem like you don't understand what `create-react-app` is for. `create-react-app` is not a hello world, it's application scaffolding. Imagine if I said Ruby's hello world was 1 million lines because I had started with Rails. That is what is happening here.<p>Show me what longwood looks like when you have a large complex application with several re-usable components, <i>then</i> compare it to react. It's very easy to create "clean" minimal libraries that do nothing more than hello world. The complexity comes from building actual applications.
The criticism feels weak.<p>1. Javascript doesn't have the same semantics as dart and swift. Both of those languages provide features like named parameters which makes it much nicer to write composeable functional UI. The ecosystem is different. React chose to mimic html-like extension to hide their API because they were targeting web developers. Swift and flutter had to target mobile developers.<p>2. There are other options than create-react-app that you can use which aren't as bloated. You don't need create-react-app to write a react application. It's a combination of sensible defaults, support for older browsers, polyfills and much more. You can use react as a library by installing it through npm without other packages.<p>3. Any library will have an ecosystem around it eventually if it gets popular. You can't stop defaults, conventions and patterns from emerging as a result of learning and figuring out the pain points.<p>The rest is author describing his project.
It's funny that the idea of "moving the element name to the function name" is literally what Perl's `CGI.pm` did probably 25 years ago:<p><a href="https://metacpan.org/pod/distribution/CGI/lib/CGI/HTML/Functions.pod" rel="nofollow">https://metacpan.org/pod/distribution/CGI/lib/CGI/HTML/Funct...</a>
I agree with a lot of this criticism. Babel is a very gnarly beast and while it once served a very critical purpose, it's time to start sunsetting it again now that most browsers support modern JS.<p>As another alternative to React that's very lightweight and doesn't need much tooling, checkout Mithril[1] which is my go to for most personal projects. If you happen to really like JSX, you can use it with Mithril with ease, but you can avoid JSX entirely and use Mithril's very convenient built in alternative.<p>[1]: <a href="https://mithril.js.org/" rel="nofollow">https://mithril.js.org/</a>
It's probably a bad idea to say "X is wrong" when you haven't done enough market research.<p>OP seems to think he's invented some completely new way of doing things but i wonder if he's seen things like:<p>- Mithril: <a href="https://mithril.js.org/" rel="nofollow">https://mithril.js.org/</a><p>- Cell: <a href="https://github.com/intercellular/cell" rel="nofollow">https://github.com/intercellular/cell</a><p>- Hyperapp: <a href="https://github.com/jorgebucaran/hyperapp" rel="nofollow">https://github.com/jorgebucaran/hyperapp</a><p>and so on. I dislike React more than anyone else for its bloated way of doing things, but there are always legitimate reasons why people use things they use. The announcement would have been more productive if he just shared the project in a humble manner.
As is often the case with these discussions, there's seldom an absolute right or wrong, but a "so what" relative to a goal.<p>My impression of the point of React is that it allows you to quickly write web apps which are reasonably structured/maintainable, performant and not flaky. My recent (non professional experience) with React seems to confirm that it indeed achieves that.<p>It was indeed originally weird to me to do react-create-app and have all the magic happen behind the scenes, but again, the goal is to get you up and running fast and it achieves that. You can whittle it down later or start from scratch if you want.<p>More importantly, writing in react doesn't (seem) to make you hate yourself. I was able to structure my app so that it's logical and changes to components can be made in isolation - that's already huge. More important is the question of "how much code am I forced to write that I don't want to write" - the answer is not much. The most annoying thing I find is having to kinda manually handle changes to form fields but otherwise it's pretty reasonable. So it feels like it succeeds on its goals.<p>Once we get to esoteric things like "JSX is bad" or "Hooks are dirty" -- ok? I guess I am not sophisticated enough to understand why that is so it doesn't bother me, and again, React seems to strive more for practicality than ideological purity so whatever that tradeoff is, is likely right.<p>Full disclosure - I am not a professional web developer. Last time I made money making websites was 2003, though I did recently build <a href="https://playdurak.gq/" rel="nofollow">https://playdurak.gq/</a> with only JS and CSS on the front-end, and currently am learning react as I build a webapp for my own purposes.<p>Edit: I guess if anyone actually wants to play the Durak game, here are the rules. <a href="https://gathertogethergames.com/durak" rel="nofollow">https://gathertogethergames.com/durak</a> I built it for my friends and I who already knew them.
Great points. I agree with them completely.<p>There are a lot we can do though, without leaving the React ecosystem. (Which you probably shouldn't because of React's popularity)<p>1. Ugliness of createElement API and JSX:<p>There is always Hyperscript: github.com/ohanhi/hyperscript-helpers.<p>2. CRA:<p>CRA is a monstrosity all right, which becomes more obvious when one has the misfortune of ejecting it. But it's not required at all. One can easily get away with a ~100 line Webpack config or with Parcel for simple scenarios. This is what is already happening, a lot of experienced users are avoiding CRA.<p>3. Hooks, fibers, suspense:<p>We don't have to use them. We have HOCs for years which are simply the React version of the venerable decorator pattern so actually no one needs a silly abstraction such as hooks. And I don't think fibers & suspense are features that the average React user needs to use at all. Just forget about them. Until you really really need them, but you'll know when this happens.<p>4. Global state and black magic:<p>Because of Redux' popularity, at some point a lot of developers started to believe that we should shift as much state as possible to a global data store. This resulted in a lot of unnecessary complication, pain and suffering in a lot of codebases. But of course this mindset is not to be blamed on Redux nor React itself. It is just the result of a poor understanding of state management, patterns established around this poor understanding, and copy paste culture. Global state is definitely not bad per se and not really threatening when it's experienced hands working on it.
A lot of the code create-react-app generates is for the build/compile step. Hopefully leveraging things like native browser module loading, perhaps with polyfills for fallbacks, will become more commonplace for major frameworks in the future. Generally I think this post makes some very good points.
The browser standards are behind. The img tag is wonky considering the various screen sizes and bandwidth variability today. Loading fonts is sketchy and weird. Anything to do with video is terrible. Anything to do with networking is terrible.<p>React and its ecosystems of libraries turn the browser in to something you can actually get stuff done with. Sure, it's a monster. But your codebase would be as well if you tried to fix all the janky crap in the modern web.<p>I don't want to program all my logic somewhere else. Front ends run on the client computer, I can keep one client's heavy computations separate from another client and it doesn't cost me anything. Fat front ends are the defence against expensive cloud providers or unstable self-hosted services.
Here's the TODO example, which is at the bottom of the post:<p><a href="https://codesandbox.io/s/competent-swartz-beoub?file=/src/TodoComponent.ts" rel="nofollow">https://codesandbox.io/s/competent-swartz-beoub?file=/src/To...</a><p>Not very readable
Hmm only a few points are valid in this criticism, I think.<p>- the jsx syntax helps hide massive nested functions. It would be a nightmare to manage any application without it.<p>- react has grown fat and does more stuff. Also it has a lot of foot guns with hooks.<p>- the create react app situation is absurd from this narrow point of view but when looked at from a project's perspective any team is going to choose it. The amount of features it offers out of the box would be insane to setup on our own.<p>- react has the biggest community right now and that will give a huge boost. Any good OSS library is not just about code and but also the community/ecosystem.
<i>I think a good view rendering library should do just one thing well: Render the UI based on the app's state. It should not care where the state is, and most importantly it should not handle the state itself.</i><p>This is nice in theory, but in any non-trivial application, a huge amount of state exists just to support the view. It actually makes sense to keep the view stateful and it's counter-productive to further segregate view-specific state.<p>You can still keep large parts of your UI functional, but the idea that your whole UI should be a function from state to view seems misguided.
Before JSX, you'd have to find a templating library like Mustache or Handlebars. You'd have to keep your templates somewhere (the usual convention was a script tag), read them in, compile them, etc.
I used to use React a few years ago for all my projects, and a friend recommended I try out Vue, and I rewrote my massive project in less than a quarter of the time. And in the past year I discovered Svelte/Sapper, and I rewrote my app in even less time than that.<p>I guess my real point is React is great, but not for all use cases, and I've come to really love using Sapper for my purposes (small, fast API-driven MVP web apps built by a single person team)
My first modern framework was VueJS, but everyone was urging me to learn React or Angular. I have too many projects on my plate to learn the last two now that I'm deep into Vue, but I'd really like to hear how the three stack up. The reviews I've seen online aren't particular in-depth.<p>Is this article a case of "every framework has warts", or are this issues really that bad?
How about just what a giant pain mixing hooks and older code is? So far I've only used react with a side project where one developer knew and loved hooks and the others didn't. The number of difficult to understand integration errors related to hooks and other (older) react techniques was impressive.