251–260 of 288 posts
> Just F#$%^& use Rails. No, just no. Or maybe it depends. But if you want to provide a lovely, modern, interactive frontend, you can't just blindly ignore what evolved on the frontend ecosystem for the sake of your purity. It's arrogant and dismisses all the people who love to craft enjoyable frontends. Following some thoughts about how to merge Rails and modern frontend approaches and how Inertia finally solved tha…
Earlier quoted context omitted.
“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.
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.
With fibers (React >16) and a couple commonly used hooks you'll easily hit a thousand high call stack.
This article has been re-written for over a decade. The so-called "complexity" is just a list of tools that each solve a specific problem. Tooling isn't the problem: The complexity is inherent to modern web development. You see similar "hidden" complexity in other frameworks like ASP.NET, and GUI desktop frameworks as well. If you're using Rails as an API backend with React handling the frontend, it's almost a comple…
Also, browsers have really stepped up their game. Now there is native CSS nesting[0], cross-document view transitions[1] and much more. So the above calculus is continuously shifting. So much that I think it's best to start with a really simple stack nowadays.[2]
[0]: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_nesting...
[1]: https://webkit.org/blog/16967/two-lines-of-cross-document-vi...
Earlier quoted context omitted.
I like that too, in theory. We used to call that "rich client". Basically UIs that had full database access. And there begin the problems. Do you really want to expose a full CRUD API, or are there consistency/security rules you want to enforce? That's cool, but makes API design a little more challenging and frontend development a little more frustrating. SSR eliminates a lot of these problems, and for many types of…
Do you really want to expose a full CRUD API, or are there consistency/security rules you want to enforce? That's cool, but makes API design a little more challenging and frontend development a little more frustrating. fair point, however i don't see that as a drawback. the security/consistency rules you want anyways. and an API makes it easier to enforce them and not allow people working on the frontend to get aroun…
For SSR, the devs working on the frontend can access anything they like. Sure, in bigger teams and for important consistency rules you'll want to encode that, but it's all a _very_ solved problem with stuff like Django.
Nope, not currently hiring :/
Earlier quoted context omitted.
> 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.
“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.
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 () => Razzle Dazzle? Nah, surely not
Earlier quoted context omitted.
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
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.
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
What would be an comparable example in the DevOps world? (honest question, I am not really familiar with it)
Imagine you want to deploy some microservices to Kubernetes. You can just create EKS/AKS/GKE cluster from the GUI, `kubectl apply` a few resources and create a load balancer to point your domain there. That will work. But... You probably want to automate the infra creation (so Terraform, Pulumi, CDK...), you want to automate building (so GitHub Actions, Jenkins, Bitbucket Pipelines, GitLab CI...) and artifact storage…
Earlier quoted context omitted.
Counterpoint: These tools add complexity, and you don't need them. If you step out of the system and look in, you see madness. The problems they solve are created by other tools; they are problem-generating systems.
That's like saying the Unix philosophy adds complexity because it dictates a tool should do one thing well. Composition of tooling (consisting of many individual tools) is the basis for lots of rock-solid stacks. I don't think the Unix philosophy is universally correct either, but "too many tools" is a complaint without much consequential basis. It's an aesthetic problem not a functional one.
The unix approach works because the tools themselves almost never change and the platform doesn't change either.
Web tooling changes, and the web platform changes. The more tools you use, the greater your risk. If something changes and you coupled 100 things together, you have to do a lot of changes. If you control it and delegate stuff to standard browser functionality, you have to do less changes.
There's also the issue of tools going out of date and being deprecated. Again, that's risk.
Earlier quoted context omitted.
You know Stimulus is for writing JS, right?
Yes. It's also recommended to not use much of it and do almost everything else with turbo drive, or turbo frames, or with turbo streams, or with whichever convoluted magic you can do to avoid it until you can't anymore. Then you use Stimulus. Yes, I know it. The fact people can't escape JavaScript doesn't stop people from being JS haters.
It's the C++ of scripting languages. I love C++.
But would I use C++ to write a modern application? Uh, no. Not unless I'm forced to.