[mosselman]

Complexity is not inherent to web development. If anything it is now possible to get more done with less.

Hotwire is sort of vanilla rails and it enables you to create very modern experiences with content live updating through web sockets and it is basically a one liner to setup.

The de facto way to deliver JS in rails has also become far simpler through import maps. There is no build step for that. Tailwind support is a flag away when generating a new rails app and is super simple.

Deploying has even become simpler through kamal.

So no, complexity is not inherent to web development and the article is wrong in marking Hotwire as “complexity”. If anything it makes it simpler.

I agree with your point about learning, but learning shouldn’t be about learning more tech. The learning should be how to get more done with less. Anyone can use 20 different programming languages and servers, the skill lies in using 4 of them to do the same and outperform a thousand person team with just 3 devs.

[mkhalil]

>> "Complexity is not inherent to web development"

>> "Hotwire is sort of vanilla rails and it enables you to create very modern experiences with content live updating through web sockets and it is basically a one liner to setup."

My point was that web development isn't complex, but the core is simple; but modern web development is.

Your "Hotwire is sort of vanilla rails" statement is a perfect example.

What you claim to be simple, is a big list of tooling, web-sockets included, integrated together. The end result is using it might be a "one-liner", but that doesn't mean it's simple. And that's OKAY. Because simplicity should be the standard; and adding things, like sockets for live updates, should be something you explicitly enable (with modern web-apis, its definitely simpler than it used to be, but that doesn't mean its simple)

[AstroBen]

This really is different. Hotwire is simple. You can read through the library's codebase and understand what it's doing fairly easily, and then when working with it the flow is straightforward. Good luck doing that with React

[creakingstairs]

> Good luck doing that with React

Data is sent to React by inertia/graphql/whatever and React renders it. It’s pretty straightforward.

Edit: I do love LiveView/HotWire/HTMX etc but honestly everything is a trade off and there are times just rendering a react component is less complex.

[ricardobeat]

“Just rendering a component” takes thousands of nested function calls, covering a million lines of code; it’s not possible for a person to read or understand the whole process unless they dedicate months to it.

[creakingstairs]

Sure it adds complexity, but isn't that what abstractions are for? We are talking about grokking how data flows in _a web app in Rails_. I wouldn't think usual workflow requires going into actual inner workings of React :p

[AstroBen]

Well React doesn't come by itself. You need a router, probably some way of managing shared state, bundling, compiling your TypeScript, and 7 other libraries

The more stuff you add on the harder everything is to understand, and the less stable your app becomes until suddenly you need specialists for every piece just to keep things chugging forward. Everything needs greasing and maintenance over time..

..and then in 4 years the React team decides "oh you know what the way Svelte is doing things is actually way better.. we'll need a re-write to integrate their ideas". Now what?

"that wouldn't happen! so many businesses depend on React!".. uh they have no obligation to make things compatible with whatever you've built. They're not working for you. What happened with AngularJS? Vue 2?

Hotwire is easy to understand (React "just renders it" is a massive oversimplification)

If Hotwire rewrites? I create a private fork and continue on. Who cares

If I want to tweak how Hotwire works cause it'll benefit my app specifically? I do it myself

I'm not against adding complexity.. but if you care at all about longevity and long-term productivity then adding React really needs a tonne more consideration than it gets

[lambdaone]

Once you give up any hope of understanding the inner workings of the frameworks you are using, you're no longer a programmer, you're a cargo cultist. Now compound this a dozen levels deep, with systems piled on systems built by people who don't understand the other systems they are building on top of, and you have the current mess.

[spoiler]

And you think slapping ActiveRecord to a Ruby class doesn't hide thousands of lines of code?

Do you need a truly holistic and in-depth understand of every piece you use? How in-depth does you understanding need to be to use ActiveRecord/ActionCable/etc? What about underlying libraries? Protocols? Engine internals?

Do you need an in depth and holistic understanding of React and all its dependencies to write () => <div>Razzle Dazzle</div>? Nah, surely not

[nine_k]

I don't think a typical React rendering call is even 100 calls deep. React itself adds maybe a dozen frames. Your components could be complicated, but likely they don't add more than another dozen or two. React is pretty efficient if you hold it right, and use for its intended purpose, that is, large and complex interactive UIs.

[ricardobeat]

The event handling alone is almost a hundred calls deep. Because a lot of the work is happening asynchronously, you won't see most of it when stepping through the debugger starting from a click handler for example, but try adding a breakpoint to the compiled JSX.

With fibers (React >16) and a couple commonly used hooks you'll easily hit a thousand high call stack.

[vhcr]

You also have to take into account the browser and OS call stack.