by jehna1 on 1/7/21, 9:19 PM with 74 comments
by alfonsodev on 1/7/21, 10:20 PM
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.
So with Typescript + Controller pattern + DDD concepts I'm quite happy with the separation of concerns.
This is how a route looks with Controller pattern.
<Route exact path="/:username">
<SignedInLayout backgroundType="paper">
<ProfilePageController>
{(props: ProfilePageProps) => (
<ProfilePage {...props} />
)}
</ProfilePageController>
</SignedInLayout>
</Route>by aprdm on 1/7/21, 10:17 PM
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).
> create-react-app
I disagree. It is clearly intended as a quick start, people can customize or opt out in one command (and remove whatever they want).
It is very functional and engineers get a production ready layout and build system in < 1 minute.
It doesn't force you to use it, use it if you want.
--
Finally your example doesn't look much better or clearer than using the React API directly..
by nemothekid on 1/7/21, 10:17 PM
Show me what longwood looks like when you have a large complex application with several re-usable components, then 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.
by searchableguy on 1/7/21, 10:26 PM
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.
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.
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.
The rest is author describing his project.
by matt-attack on 1/7/21, 10:25 PM
https://metacpan.org/pod/distribution/CGI/lib/CGI/HTML/Funct...
by vorpalhex on 1/7/21, 10:30 PM
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.
by zer0tonin on 1/7/21, 10:10 PM
by cocktailpeanuts on 1/7/21, 10:36 PM
OP seems to think he's invented some completely new way of doing things but i wonder if he's seen things like:
- Mithril: https://mithril.js.org/
- Cell: https://github.com/intercellular/cell
- Hyperapp: https://github.com/jorgebucaran/hyperapp
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.
by xyzelement on 1/7/21, 10:30 PM
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.
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.
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.
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.
Full disclosure - I am not a professional web developer. Last time I made money making websites was 2003, though I did recently build https://playdurak.gq/ with only JS and CSS on the front-end, and currently am learning react as I build a webapp for my own purposes.
Edit: I guess if anyone actually wants to play the Durak game, here are the rules. https://gathertogethergames.com/durak I built it for my friends and I who already knew them.
by gwn7 on 1/7/21, 10:32 PM
There are a lot we can do though, without leaving the React ecosystem. (Which you probably shouldn't because of React's popularity)
1. Ugliness of createElement API and JSX:
There is always Hyperscript: github.com/ohanhi/hyperscript-helpers.
2. CRA:
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.
3. Hooks, fibers, suspense:
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.
4. Global state and black magic:
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.
by harrisonhope on 1/7/21, 10:19 PM
by jbob2000 on 1/7/21, 10:15 PM
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.
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.
by o_____________o on 1/7/21, 10:13 PM
https://codesandbox.io/s/competent-swartz-beoub?file=/src/To...
Not very readable
by vijaybritto on 1/7/21, 10:20 PM
- the jsx syntax helps hide massive nested functions. It would be a nightmare to manage any application without it.
- react has grown fat and does more stuff. Also it has a lot of foot guns with hooks.
- 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.
- 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.
by incrudible on 1/7/21, 10:20 PM
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.
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.
by atarian on 1/7/21, 10:42 PM
by yawnxyz on 1/7/21, 10:48 PM
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)
by SoSoRoCoCo on 1/7/21, 10:41 PM
Is this article a case of "every framework has warts", or are this issues really that bad?
by topkai22 on 1/7/21, 10:31 PM
by recursivedoubts on 1/7/21, 10:51 PM
Don't feel too bad about it. The industry does this stuff every decade or so...