Programming is my passion. There's nothing better than working as a team, together to deliver something working to the users.
Working together cre...
For further actions, you may consider blocking this person and/or reporting abuse
For my perspective there is no such thing like "X group of people have more complicated tooling". For a frontend dev, the backend tools seems to be more complicated, while for backend is the oposite and it seems to be very normal, because they have diffrent way of working, goals, background and often even attitude or type of personality.
As you said, it's hard to be good in both, and I don't think the Hotwire (or the approach in general) will change that, so why "force" one to be the other? Let them be experts in one area and it will be beneficial of both "sides", because people always work on the stuff that they comforatable with and will be able deliver as good backend / frontend code as possible, due to their extensive knowledge in that area.
Unfortunalety it's a model where one developer probably can't deliver the whole solution, but isn't that just sing of the times we live in, that things are not simple anymore and it's extremely hard for a single person to be as least good enough in all things necessary to deliver?
Anyways, thanks for this post, realy like it, make be think πββοΈ
Thanks for sharing your perspective here.
I'm not accepting the current status quo around frontends/backends - I find it over-complicated and not productive at all.
I also have a different opinion on tooling - it's not subjective. Tooling ecosystem, while hard to measure is in some cases less mature or more mature and thus can be objectively evaluated as worse or better. Frontends just didn't have enough time to mature similarly to some of the backend ecosystems (not all).
Finally, I'm not fine that one developer can't deliver a whole feature alone. While I agree that things are getting more complex, I don't think web overall has to be that complex as it is now.
Peace :)
I cannot agree with you more. The whole front end / back end thing has created a huge amount of friction. As you say a single developer should be able to understand and deliver a feature. It causes friction between developers (I don't mean arguments, just that things slow down), and it causes friction between the customer and the developers.
I've worked on full stack teams a few times, and each time I find people are still drawn to one side or the other. I always ended up with the front end work and the backend-focused developers always shied away from it.
I've also worked at places where the gulf between FE and BE devs was so huge, there was some real animosity between the 2 sides.
The problem is that all BE developers think the whole app should be served up by the backend, and front end devs think the entire app should be driven by js.
For me ive found the best way to keep the 2 sides in parity is to work on having a similar architecture and ethos between the 2. If a backend developer looks at the frontend code and feels familiarity with it, that lowers the supposed complexity barrier immediately.
Man you said it. That is exactly why we use hyperstack.org at our business. Sure some folks are better at front end and others are better at backend, but at least with a framework like hyperstack (there are others) everbody can read, understand, and fix everybody elses code.
Article hit all the right points. Wish you had mentioned hyperstack.org . I recently did a little comparison of Hotwire vs Hyperstack here: medium.com/@mitch_23203/hyperstack...
The nice thing about Hyperstack is its goal is to completely bust down that barrier between front end and backend.
Thank you for this comment β€οΈ
Indeed, I could have mentioned Hyperstack. I love all the Opal ecosystem but never found enough time to see how cool it is exactly.
Are there non-Ruby such ecosystems?
For javascript there is meteor.com/
Of course I am biased as a core contributor to hyperstack but indeed it is pretty cool. You simply write the same code on client as you would on the server. Even back in the "good ole days" of HTML, you had to mix HTML with Ruby using ERB. In hyperstack you just write your front end component code (roughly like a rails partial) in Ruby. All your active record models are accessible directly on the client using the same AR API that you would on the server.
I don't think it would be possible to build such a productive system in any other language because 1 - Rails gives you so much to start with, and 2 - Ruby is so good at building clean DSLs and APIs.
Huh? There was frontend. In my own and many colleagues' experiences, it was similarly separate, albeit in slightly different ways. We frontend folks weren't considered real engineers back then, not with our managed hosting, relatively simple query-and-display code using templates, and our design sensibility that cared more about human factors than about what Facebook funded. Some people say that frontend folks had a desperate need to prove they were just as SMRT as any engineer and that some of them decided to make frontend more like backend and ruin it for everyone else. A mess has certainly been made, but who can really say why.
That aside, this next generation of stuff that tightens the integration is very exciting. I'm particularly interested in no-sweat trisomorphic rendering.
Htmx, successor to Intercooler
Thanks! I didn't know about this one.
Thanks for mentioning it. I learned about it two weeks ago and am eagerly watching that project.
A barrier sounds like a organization problem. Iβve never worked on a team where developers were not responsible for the entire stack.
Neither me, but when I talk to the people around it's clear that the separation is the mainstream now.