Follow

I will die on the hill that front-end work is a horrible mess, and I can't deal with its senseless complexities anymore

So I spent some time this morning, yet again, going through the motions of a react stack, then Vue. Both felt too big, the amount of code I'd write was far bigger than the perceived benefits

Then there's (wrapped) webpack, the test stack, bundling and minifying, sometimes transpilation... Half of these tools will be replaced in two years or so. Some already are outdated, but I wanted to cut off time by going to tools I'm already familiar with

Long story short, I scrapped everything. Going with good old server side rendering. Should it need an SPA, it can be added later. I feel so much productive now

@urso <whisper>Elm</whisper>

(but also yes, it's a mess in general and I'm glad I stopped doing/following it years ago. I'm thankful some people can deal with it so I don't have to.)

@celestial_monarch @urso please do. I don't have much use for it as I don't do front-end, but from what I've tried it's quite good, and friends really like it.

@shello @celestial_monarch I don't do languages that transpile to js, mainly because of awkward experiences with other languages (clojure script, mainly)

I like haskell but I'd rather not have to learn another language to develop a top heavy frontend that in principle doesn't need that much complexity

@urso @celestial_monarch Absolutely fair points. While Elm isn't very hard to learn it's its own thing with its own conventions, etc. And having to set up an entire separate stack to do something simple shouldn't be necessary.

That said a nice thing about Elm is how it generates small JS files that are runtime stable. But it's still a lot to ask for a basic job.

@shello @celestial_monarch also the burden of the next developer having to maintain it. I always have this in mind when choosing technologies.

And I do think Elm is a bit difficult to grasp for the average developer lmao

@urso @celestial_monarch Many devs just seem to be weirded out by functional paradigms, so that's not a surprise :P

As for the burden, tbh, anything that's not just ECMAScript is always going to be a burden.
The last thing I remember seriously using was AngularJS 2 and honestly it was a burden even for me. 😬

@shello @celestial_monarch I don't think it's much the functional paradigms, but the haskell heritage. By my experience, it makes grasping functional concepts a bit harder depending on the individual

@celestial_monarch I don't think anyone is at fault here.

Maybe I'm just bitter. But I'm almost, almost sure 90% of projects using react and other shit on top didn't really need its complexity to begin with

@urso yes, I find it to be a difficult situation, because on one hand there’s a lot of complexity for solving basic HTML features, and at the same time for a dynamic page I’d rather deal with a react.js codebase than a jquery or vanilla JS codebase because it offers some sort of structure and offer some sort of predictable DOM

@urso (I might be biaised as I have been working on both front and back ends on JS for 5 years now)

@celestial_monarch oh my God, for a really small (functionality wise) page, I'd much rather deal with server side rendering and some optional js to enhance things here and there. It is much less code, hands down, and I'm less prone to breakage or backwards incompatible changes down the line

And with most browsers, just vanilla js is already fine

@celestial_monarch I'm more of a back end kind of dude, and a good number of data validations on the front end should also be done redundantly on the backend anyway. I've submitted logic-breaking forms many times just by tweaking js and checking whether the server is doing what it is supposed to

@celestial_monarch maybe, for example, Mastodon's logged ui is one of the examples where an SPA fits. I think hotwire and Phoenix's live view convinced me that reacts "solution space" is smaller than it seems

@urso oh I agree with you, I was referring to pages that are both distributed via a templating framework but also come with quite a bit of vanilla JS or jQuery to add some dynamism to the page. If it is very minor modifications to the DOM that are needed then what you suggest definitely makes sense

@urso I’m curious to see how much Phoenix Live View (Elixir) helps the situation

@banjo I'm actually considering hot wire (from the rails folks), which I hear is the same thing. Allows me to develop server side rendered and then later cheat out with it

@urso exactly! I worked through a textbook on elixir and had quite a bit of fun with it

@banjo backend is clojure, so hot wire (turbo frames, I think?) seems a bit more ready to use off the shelf. Promising, but I'm not committing to it yet

For what I need, it is almost perfect. It's either that or good old server side code with sprinkles of js here and there

@banjo because I swear, if I have to fight another webpack or flavor of the day build system again, along with the myriad of complexity around react (and the others!), I'll die soon

@urso every time I’ve tried to learn it, it makes me never want to touch a computer ever again.

@robdaemon I've worked in many places where senior engineers make smart libraries on top of react (itself already a fairly complex piece). I could never justify the extra layer for the so called "features"

@urso I'm a "principal engineer" - and by the time you get to my level, you're good at deleting code. I look at most frameworks and turn up my nose. Too much added complexity, too little benefit.

What makes the frontend stuff worse is the rate of breaking changes in it - I think it's impossible to keep up with it, and still focus on making a product.

Sign in to participate in the conversation
Bear.community

Bear.community is a 18+ only Mastodon server for bears, chubbies and chasers.