React I love you, but you're bringing me down

The issue is usually frontend pedagogy or the lack of it. Maybe things have changed but when I graduated undergrad CS in 2017 the extent of frontend being taught in my school by professors was "hand write some HTML, maybe some PHP if you're lucky". I've never met anyone who learned frontend anything in school to a degree that matters, so everyone is either learning from other junior devs on the job, from blog posts that are often wrong, or from a backend engineer who was pressed into learning frontend.

Yes, JS has a very tortured history coming from the fact that it was not intended to be the long-term development language for web interactivity from the start, but we also don't really teach how to do it properly.

But with functional components I think React gives you something substantially more debuggable than an object instance with random method calls that manipulate the DOM.

React functional components (with hooks) mandate a very specific control flow that probably halves the debugging surface for any given bug, saving time.

You do have to exercise restraint when incorporating third party libraries, but if you can do that it can be a very rapid development environment.

Mithril is reactive out of the box, and just works. It smokes React in every category, but still has an optional JSX integration if that's what you're comfortable with.

https://mithril.js.org/

https://svelte.dev/

Custom elements are really neat, and may very well do what you need. The big pain point that React solves (for me at least) is that you get to define your views declaratively instead of imperatively.

This is exactly what I do on SPA front ends for many of my customers. Of course we use some libs but those have nothing in common with the frameworks, just narrowly scoped solutions. Saves gobbles of time and money.

  1 https://paulfrazee.medium.com/building-on-budget-4b91b43d0357

People get promoted for all the shiny new things they do, not for the discipline they show in only focusing on what really matters.

I don't think this is related to losing sight of the big picture, no more than focusing on good clear sentences means you can't write Anna Karenina.

But I do agree that sometimes the big picture is lost, with tasks that have been broken down inappropriately.

I have a suspicion that partly this is driven by open plan offices: tasks have to be broken down, as focus is a luxury.

What I mean is that even if you've followed a specific set of programming principals, code practices and design patterns consistently across the life time of the application, there will still have been initiatives to change how things are done. Maybe they want to use a "better" authentication library, or add a material framework that has capabilities they need. The exact initiative, and how valid the request or decision is doesn't matter. These initiatives may occur one at a time, or be competing with each other for priority while being incompatible without anyone noticing. But some of them will fail to be completed, and someone has to back out the changes that shouldn't go to prod. Inevitably something will get left behind. Over 5-10 years this can have a shockingly large impact on the code base in ways engineers frequently notice but don't understand how the code got to the state its in.

This frequently means dead code, unused dependencies, comments that don't make any sense, properties on objects that are never displayed or referenced by business logic, and multiple classes/services which accept the same inputs and produce the same outputs but do the job just differently enough you can't be sure it's the same. That, and over abstractions (any piece of code which branches based on the context of "who's asking").

And frankly few things any me more than someone who felt the need to implement their own logging implementation, especially in C# (yes I know we're talking about React, but people do the same stupid crap in that case as well). Reinventing the wheel has to be done on occasion, but you need to ask yourself if it has to be you that makes it happen,and whether it already has been.

This is so silly. Hooks are literally hooks into a scheduling algorithm you are at the mercy of. That scheduling algorithm is pure JS. Of course you don't have classical control flow in someone else's scheduler.

The key users are referring to when talking about "JS vs magic" is that React is just constructing objects and invoking functions, with known semantics, whereas Solid and Svelte are auto-magic-reactive systems without clear semantics rising from the choice to do even more things in their internal black boxes than React, such as never re-rendering components, dark compiler magic on syntax that doesn't naturally map to a JS tree, and other such things

They literally are.

> hooks aren’t JS

The code in React executing components relies on hooks running in a consistent order each time the component runs, but the existence of a runtime context that has expectations about side effects (and hooks are side effects) doesn't make it “not javascript”.

Is that just down to Svelte, though? Or is it the greenfield effect? Projects always fly quickly at first, when the code is fresh and unconstrained, and you're building the basics.

My concern would be when things get complicated and you have to debug Svelte's binding magic - and I have very bad memories doing that in Angular and Knockout.

That being said, the Vue2 -> Vue3 migration has felt pretty frustrating. It's felt like, with enough work, I could eventually get Vue to behave similar to React.

> I still think Vue (especially Vue 2) is the greatest of them all. I've worked professionally with Angular, React, and Vue. Each for several years. Vue is easily the winner for me with the syntax that closely matches native HTML and JS/TS and how it encourages clean separation of concerns and clean code. JSX/TSX is absolutely the worst for the latter, it's like the wild west. "But you don't have to write it that way" - yeah ok, but when you work in a large organization it's going to get written that way by your peers; good luck trying to stop it. Angular is just a clusterfuck of pipes and observables that require higher cognitive load to unravel when trying to understand a semi-complex block of code. Contrast with Vue where I can near instantly understand what it's trying to accomplish.

> This shit right here - {#if <condition>} {:else} {/if} - is why Svelte is deterring me. For the love of god, can we stop coming up with weird custom syntax for templating code? This is one area where Angular also pisses me off: *ngIf for example is just as hideous. With Vue: v-if, v-else. You add it as an attribute to native html, it's dead simple. No weird symbols, no braces or other oddball shit I have to look up when I step away from it for a few months and come back. It just makes sense right away.

It is built on top of web-standard; I am surprised how (lit)tle attention it gets on HN (so far).

That is why it is not discussed that much. If you need to write components, then lit may work for you, but whoever wants to ise those components would prefer a js framework.

Also, lit is from Google. which makes it worse as Angular is from Google as well

I've given it a fair shake and I wish I could change this opinion. I'm trying not to rant so I'll stop here.

I do a cathartic exercise every time this stuff gets to me at a themed twitter account. It's pure vitriol: https://twitter.com/sisnode

[1] oftentimes I see the anti-react argument as "react sucks which is why I use Y framework". I'm saying they are all(?) a toxic trend that leads to terrible products; more complicated, harder to maintain, aggressively encouraging a glossary of programming antipatterns passing it off as elegance.

The more you deviate from one of the set of common conventions, often enforced by frameworks, the more you have to build on your own.

The larger your project gets, and the more developers who need to understand your code, and the more developers you need to hire and get onboarded quickly, the more that those extra rules start to make sense.

And once you've learned and internalized the patterns necessary to build larger systems, it becomes force of habit to just use it wherever, even if it's nominally easier without them. For most developers, a go-to pattern will be faster than working from first principles on every project.

Then you exactly describe MVC...

> state data in one object,

This is your model.

> save it on each user interaction,

This is your controller.

> and use it only on page refresh.

This is your view.

MVC is a relatively simple concept, and it works well.

We must work on very different kinds of projects. I really can't imagine plain JS being a viable or appealing solution compared to Vue, which gives me very little grief at all.

Doesn't that mean you can never reflect state updates in the DOM without refreshing the whole page?

> I have never understood why people find state management challenging

Automatically determining what DOM objects need to be updated in response to a change in state and updating them without a page refresh adds a lot of complexity, if you completely ignore that requirement then state management would be simple like you said.

Yes, seriously. Have you used it for more complex components? You can split your effects across multiple useEffects, and have a guarantee that they run completely independently of each other (especially since you know what their dependencies are). Compare that to lifecycle methods: you only have one per component. All your effects concerned with setup have to be piled into the same function, and their associated teardowns have to be elsewhere in another method. How do you audit a behavior's logic? How do you reuse that behavior in another component? It's not easy, and you can cause weird bugs depending on the order in which you run them.

Compare that to useEffect. Setup and teardown in the same function, which allows it to focus on just one behavior. And if you need to, it can be trivially pulled out into its own hook and reused across all your components.

A lot of third party hooks are really good though, being able to hook a dependency rather than create higher order components saves a lot of time and is conceptually much easier.

https://reactjs.org/docs/error-boundaries.html

That's not strictly true. You can implement "hooks" on top of a class based components. It's essentially the strategy pattern.

* SHOW HN: UberTinyUltra.js Here's my new super light-weight 4k Javascript Library!

* How I switched to UberTinyUltra.js from PopularFramework.js and simplified my life!

* SuperCoolStartup switches to UberTinyUltra.js

* How I built my unicorn on UberTinyUltra.js

* UberTinyUltra.js 2.0 now with a compiler, classes, typesafety and a C++ like turing complete template language to take on the big enterprise jobs because we have too much time, attracted a lot of developers to the project, and ran out of obvious simple features to implement!

* I hate you UberTinyUltra.js you are too complicated.

* ShowHN: SuperTinyMega.js Here's my new super light-weight 4k Javascript Library!

God it drives me nuts that the language will allow you to spread a class into an object and it will take the properties but not the methods.

Strong agreement!

There's a saying in community organizing and activist circles that goes something like:

"Don't apply the solutions of the butterfly to the problems of the caterpillar."

Imho it's a really important consideration when thinking about scale of movements (and nonprofits... and any community initiative...). This is especially true when "professional" people are always coming in and confidently over-applying their learnings in corporations to thinking about activism (which often, though not always, has very different incentive structures and lifecycles).

I think about this parable often in regards how all these scaled tech companies end up stewarding the developer tools and therefore practices for everyone. And they tend to out-pace and out-broadcast other wonderful tools that could better serve the majority of developer niches.

In 5 years if no one else is using Hotwire then your code is obsolete, no?

I liked working in next.js in the past but my company was already talking about Nuxt.js when we hadnt even fully converted to next. Feels like jumping ships from a ship with some major flaws, but will continue to float for x+ years, onto a lifeboat that may or may not make it another 500 feet before sinking.

Step 2: Someone gets fed up with this writes a framework that "does things right" and is designed for "simplicity"

Step 3: People start loving the new tool because it is so much easier to work with.

Step 4: People start to do things the tool wasn't designed to do. They start making "minor feature enhancements" to the tool so that it can fit more use cases.

Alternative Step 4: Tool becomes "industry standard" so everyone starts using it because it is "the right way", regardless of whether or not it is a good fit.

Step 5: The new tool becomes massive and bloated and overwhelmed with too many features, configurations, and options.

Step 6: Return to step 1.

> The Wheel of Time turns, and Ages come and pass, leaving memories that become legend. Legend fades to myth, and even myth is long forgotten when the Age that gave it birth comes again. In one Age, called the Web 2.0 Age by some, an Age yet to come, an Age long past, a wind rose above the great mountainous island of FANNG. The wind was not the beginning. There are neither beginnings nor endings to the Wheel of Time. But it was a beginning.”

Did you rewrite your entire app?

I never used Svelte, but I feel that "develop a reactive piece of UI" is basically Stimulus' job description. Can you explain a scenario/task where Stimulus does so poorly, that you flip the switch and use Svelte instead?

That said, learning how useEffect replaces lifecycle methods is pretty quick to pickup. As is useState.

The lesser known hooks are what are difficult for me to understand. useRef is pretty clear. useMemo? I'm not quite sure what it's for, but I imagine it's not too tough to figure out if I spend a bit of time learning & experimenting with it.

So, although I liked the simplicity of class components, functional ones aren't too bad. They bring in some additional complications, but with a bit of effort it seems to all be learnable to me.

It’s challenging though to keep supporting an API contract that you don’t believe in anymore. Or especially that you are causing you and others pain. I think sometimes maybe the thing to do is pass the baton and work on something else, but we also punish people for abandoning things. Like the author of Groovy, who hopped around from project to project and lost people.

Hooks just match the way the React runtime works. Classes are just way easier to do weird bad stuff with. I’m not sure I would ever choose React if it was still class based. I’d use Ember probably which gives you more with the class-oriented API. Without the simplified control flow of hooks, I don’t see what React even offers over Ember or Vue.

Vue 3 also has hook now. But none of these defects in the article exist.

In vue.

To use some value in a effect, you just use it and it is tracked.

If you need to clear up your code. You cut some code into a useXxx function, and your reusable utility is done. You can use it everywhere now. You don't really need to specify dependency of whatever by yourself.

If you must manipulate a dom, you just manipulate it. It will work as long as you revert the change before vue want to update it again.(And vue do provide a hook for you to attach a handler when these happen)

These restrictions are added by the way react implements hook, but not hook themselves. Hooks are just more user friendly services (by allow the hook to attach to component instance without all the glue codes(addListener or whatever))

Someone actually did in a project once and that lead to render loops that were hard to debug or solve: https://blog.kronis.dev/everything%20is%20broken/modern-reac...

Instead of a clear message about what caused that loop and maybe a walkthrough of the last N iterations (which changes caused which logic to be triggered), the error message was just a vague and lazy error (even AngularJS errors were better back in the day, filling in details in the docs as URL parameters).

Then again, over the years I've formed the opinion that both approaches are bad, just in different ways. There is no silver bullet, just look at how even desktop software and UI solutions struggled to be workable throughout the decades, of course things won't be that much better in regards to front end.

However, Vue's approach to hooks seems refreshing: creating and nesting components still isn't as easy as in React, but getting things done feels a little bit less cryptic and not as confusing, especially with something like Pinia!

Sure. but it is better for 99% tasks. And remaining 1% can be achieved via other APIs

To me one of the biggest issue is that almost everyone is deeply afraid of prop drilling. Passing props around and having some local state works very well for large parts of many applications. With hooks we don't have deeply nested Higher-Order components anymore, if you pay a bit of attention you can have reasonably shallow component hierarchies and props work very nicely then.

Server-side state is a special case, I find that much easier to handle with something like React Query. But once that is done I don't see much need for any external state management library like Redux, useState/useReducer works pretty well.

And yes, sometimes Context is useful for state that doesn't change much. But those are the cases where the drawbacks don't matter. But that is a special case, not necessary for the vast majority of state.

> feels like so many people actually writing in React are just effing CRAZY

Same here. We had an experienced-but-batshit-crazy dev create a React site with approximately 250,000 LOC to support 3 forms with a max of 4 simple inputs and a 3-column data table view. To this day it makes my head spin how it is even theoretically possible to write that much code for so little functionality - much less _actually do it_. And don't even get me started on how unmaintainable it is - IIRC I tried to update the string content of an error message once and it required changing something like 57 lines in 10 files (or maybe it was 1 line in 57 different files? something like that...).

I would love to point to a good repo, but all the apps I’ve worked with are closed source. And I haven't seen a good open one :/

Pinky promise to finish a response here or write a blog post and post a link here. But have to go now to get some sleep

And how much logic you put into a component is up to you. Your components can be almost entirely view logic, with any other data fetching or computation offloaded to other regular js files.

I've looked at Svelte. I was deterred by lack of ecosystem. Vue's is just big enough to be workable, I think Svelte doesn't offer enough to reach the Vue/React size - probably.

Is there anywhere good to find out what I have been missing out on having not kept up to date with Djano for the last few years? I really miss using it and am looking for a job using it again.

Also, building a team is much easier. If you bring six React developers around a table, they will have six different ideas about the parts of the ecosystem they like and use.

Six Vue developers? They’re ready to kick ass from day 0.

I'm a developer that's done with this, but it brings in VC money so in my experience it serves mostly to create opportunities for CEOs to get some more money on the table via buzzword pitches.

There was recently a demo of what a Todo MVC app might look like if written in vanilla JS with today's apis. It looks fairly decent; I could see myself going back to something like that:

https://frontendmasters.com/blog/vanilla-javascript-todomvc/

Interesting that you didn't comment at all about my take on functional components not being the best tool for every job in React. Curious – do you have an opinion?

Phoenix Liveview, Elixir & OTP, and Full-stack Graphql with Phoenix.

Best way to learn Liveview.

https://pragprog.com/titles/liveview/programming-phoenix-liv...

In general Vue holds high conceptual similarity to React so React devs just "get it" straight away. However nearly everything is simpler / easier than it would be in React, so they learn it extremely fast.

an enhanced hypermedia model offers a lot more interactivity often at a fraction of the complexity, and w/ the benefits of the REST-ful architecture (flexibility, etc.)

IIRC it also only bales out during the DOM update phase; not during the calls to render() and then reconciliation(?). And if it bales out, it has to re-render everything again when it comes back to make sure the state is consistent(nothing has changed).

The exact details are fuzzy and that may be incorrect but the impression I came away with after reading an engineering post about the deets was that:

* The risk of thrashing seemed very high

* Debugging performance issues seemed like they were going to be a nightmare. Worse than right now. Worse than hook hell.

This line from the song Taro comes to mind: "Do not spray into eyes. I have sprayed you into my eyes.

Don't substitute memes for thinking. Evaluate what I've built on its actual merits.

This is on my list for the 1.0 release. Unofficially...

Edit: You motivated me to rough something out, take a look here: https://tinyurl.com/joystick-comparison

> What distinguishes your framework?

Simplicity and stability, primarily, and second: scope.

The current crop of frameworks seeks to overcomplicate APIs and are indecisive about how things should be done (as evidenced by the introduction of patterns that are "the way" one day and then a few months later are "deprecated"). This leads to a lot of confusion at the community level which makes it hard to build software that can endure overtime (I came to this conclusion through teaching developers and realizing how much time was wasted chasing the proverbial rabbit of indecision).

Even worse, these frameworks introduce their own languages/syntax which are foreign to what a beginner would learn (HTML, CSS, and JavaScript). This not only creates confusion and slows down the learning process, but it also creates the long-term nightmare of developers not understanding the fundamentals of the tools they use to build. Eventually, you hit a drop-off point where people think that, for example, JSX is HTML and in a pinch where they can't use React, are ineffective or incapable of completing the task properly.

By contrast, Joystick is designed to be stable, long-term, from the beginning (i.e., no random "hey, we're deprecating all this stuff you depend on for this more confusing API that's less descriptive"). It's also based on the core technologies of the web: HTML, CSS, and JavaScript. I don't introduce any hacks or sytnax tricks to render the component. It's plain HTML, CSS, and JavaScript. This means that the transition from learning the basics of the web to shipping apps is far smoother (and an individual developer is less likely to make mistakes/get confused as everything looks consistent with where they started).

I also intentionally designed the component API to be fixed long-term. So, a component you write in Joystick today will look the same 10 years from now. My focus will be behind the scenes, improving performance and security. This matters less to developers and more to businesses (my target) as a lot of time and money is wasted on developers who are more focused on tinkering with technology (and making messes) than actually building the thing they're supposed to build.

For scope: Joystick is a full-stack framework, not front-end only. The UI part (@joystick.js/ui) is designed to snap in to the back-end/server part (@joystick.js/node). The advantage is that you're not wasting time trying to stitch together disparate parts that may or may not work together (or even worse, may or may not be supported long-term).

> Who should use it?

SMBs, startups, and freelancers/contractors. For SMBs/startups, it's a solid framework for shipping custom software for your business (or a consumer/b2b SaaS) that you can rely on long-term. So, build it today and maintenance is limited to some patch upgrades and new features/improving existing features. Never a surprise refactor being plopped on the roadmap, distracting you and your team from delivering value to customers.

For freelancers/contractors, remove the overwhelm of juggling a bunch of disparate codebases across clients that each have their own shifting requirements (i.e., standardize what you ship, full-stack). This allows you to take on more work, but also, make your long-term support more predictable as the framework you're building on isn't going to rug pull you down the road. This allows you to build a better business with happier clients.

> What does it do? And more importantly, what doesn't it do?

It allows you to define routes on the server which when matched, render some HTML, CSS, and JavaScript using a component framework that's a light abstraction over those core technologies. It also makes it easy to define a JSON-RPC API that can be called directly from components, giving you complete transparency into the flow of data between the client and server without any ambiguity. In addition, it adds the necessary wiring to start and connect drivers for databases to your app, piping those drivers to where you need them (namely, your routes and your API endpoints/handlers).

The back-end is just a plain Express.js/Node.js app so anything you can do in a standalone Node project, you can do in Joystick without any limitations. So, if you want to use a third-party package, just run npm install <blah> and it will work.

All of this is backed by a built-in SSR/hydration implementation so all you have to do is write your routes, API, and components. No time wasted on wiring the front to the back-end. All of that is automated via the lightning-fast build system built around esbuild (which is implemented/configured out-of-the-box) so you can just run `joystick start` and get to work in a few seconds.

Thought it sounds obnoxious, what Joystick doesn't do is get in your way and it isn't a ticking time bomb of deprecation. It allows you to actually focus on the product you're building, long-term.

No, but I think your comment falls squarely in that category.

If you have anything more complex than that, like a real web application, Angular is an actual frontend framework, where React is just the modern jQuery.

Angular is for software engineers, React is for web developers.

Angular (Angular 2+) is honestly lightyears ahead of what AngularJS (Angular 1) was, so if you already preferred AngularJS over React, Angular will be a walk in the park.

I feel like a lot of people who talk about Angular being bad are actually talking about AngularJS and have never tried the newer versions.

For collaboration and onboarding new people, it's hard to do things badly in Angular, and it's easy to refactor when they are done badly, so it's a great choice.