Hacker News Reader

Comment by fny | Hacker News Reader

I have been in web dev since 1999, and recently switched to a backend role.

I am never going back.

The endless thrashing on front end borders on psychosis. Something is clearly broken, and that thing is my feeble mind.

For me I'll never go back to normal front-end work after doing Blazor with C#. It's the nice bits of React (reusable code) but the flexibility of never having to decide between front-end only focused code, or some back-end powered AJAX style code, that is transparently rendered for you. You never have to touch JavaScript, but there's ways to do so.

WASM is the best thing that ever happened to the web. When other major web frameworks adopt template engines that compile to WASM, we will see a shift in focus on JS heavy frameworks, and just people building things instead of fighting and trying to remember all the weird quirks of JavaScript.

Can you share your experience with other frameworks beside Blazor that you had a good experience with?

I have seen Blazor and it looks good but I have an aversion to anything Microsoft.

You should try it out; microsoft makes good contributions to open source software, and C# is, in my view, the best (or maybe the only good) backend language put there

LiveView in Phoenix is a similar experience, and I enjoyed (briefly) using it. https://pragmaticstudio.com/ has a good introduction.

Thanks! I took their Ruby and Rails courses and loved it. Great teachers!

I've done web dev with various other frameworks: Django, React (front-end only - no SSR), Vue, CherryPy, and a few others. Blazor is the only technology that allows me to use 1 programming language outside of HTML / CSS. You have component UI libraries like React does, so you have to think less about hand crafting HTML and can focus on per component logic / UI much like when developing with React or any "SPA Framework" out there.

Go one step further. The programming model behind Blazor server is criminally under appreciated.

Spa-style interactivity without a need for an API is great.

Optional shared state between clients and effortless push-to-client is… basically magic as far as I’m concerned.

How do you do dom manipulation in wasm code?

One of the frontend problems is that too much frontend engineers think a web app should be a single page app. A lot of apps don't need to be that. Server-side endpoints and templating + lightweight vanilla JS and framework-agnostic web components works and is now even easier than ever.

I've seen so many marketing websites written in React. It's so confusing.

clear boundary is good, I don't understand why people like to trash their back-end with templates, MVC and all the "view" nonsense. They are just shifting complexity from a place they feel uncomfortable, to where they do, but at the cost of destroying their own nirvana. Certainly one way, but hardly the only one.

> I don't understand why people like to trash their back-end with templates, MVC and all the "view" nonsense.

Because the tooling has been here for decades and it works damn fine. No need to trash the frontend with ever changing piles of dependency and build nonsense.

> works damn fine

when? View code in the back-end always looks like crap and never able to achieve the interactivity the front-end can. People wrestling with it was the reason SPA was born. There was no dictator forcing people to move on from such "awesome" working "damn fine" pipelines to modern front-end for no reason.

> View code in the back-end always looks like crap

That's probably the fault of the people writing it. People can also write crap looking code using frameworks too.

> and never able to achieve the interactivity the front-end can.

That's what small sprinkles of javascript is for. You don't need incredibly beautiful interactivity in every pixel.

It‘s a kind of collective hallucination. It‘s affected me too.

I just recently decided to go back in time and wrote a web app using Flask, all rendered server side, with a minimum of JS and JSON endpoints for a bit of client-side interactivity (e.g. autocompleting an input field). Very fast, iterative work. No duplication of data classes, no weird caching issues…

Felt like a breath of fresh air, sadly. Have we witnessed a full turn of the wheel?

That's a good old case of "the right tool for the job".

But let's be honest: the frontend dev rat race had the effect to make the base web technologies better. Better CSS (variables, nesting, effects, media support, etc), better JS (webcomponents), useful libs available as wasm and so on... all good things that can be used natively and allow us to make better MPAs.

Commercial-grade applications need some grade of offline operativity that classic HATEOAS can't provide, often target users who won't learn or can't really use a web browser (tabs, back button, extensions, bookmarks besides whatever they can fit in the bar, etc), often want to give a UX which abuses and deforms a web browser by design. Yeah, FE engineers may all look like dumbasses with macbooks (i don't think this of them!), but they have real problems to solve.

Not denying that, but just because I browse the web I'm pretty sure not all websites with "modern" frontend stacks have modern frontend problems.

That's for sure, for example any blog software (a few SSGs included) is a failure for WWW and for itself (most of the interaction between author and reader must be mediated with third-party or big cloud to avoid spam and scam).

I think most people choose SPAs because they also maintain the frontend state of a an application. If you're just serving templated html from a backend, you're probably also doing vanilla javascript which is it's own kind of hell. How do you manage the transition between one view and another on the same page? How do you pass state between two pages? I think webcomponents solve some of this but there's a lot of react developers out there who don't have the requisite software engineering skills to handle this

> How do you manage the transition between one view and another on the same page?

HTMX solves this, and it's mostly automatic. You get some nice transitions.

> How do you pass state between two pages?

You don't. You submit some data to the server, it generates HTML dynamically, you replace HTML on the frontend or redirect all together, you're done. The state is on the server.

So then you need some kind of state management on the server?

> So then you need some kind of state management on the server

Yes. You might call this an application, lol. You will require this no matter what, unless you have a fully client-side application. Like photoshop or something.

> If you're just serving templated html from a backend, you're probably also doing vanilla javascript which is it's own kind of hell.

How so ? Vanilla JS has never been easier and more powerful.

> How do you pass state between two pages?

Why is it even considered to be a problem ? This is basic stuff. All web frameworks since the 90s have had this concept of sessions where you can store data that will be available across pages.

Vanilla js is unstructured. It's very easy to write spaghetti code with vanilla js.

Sessions are a kind of global state. I mean temporary state, like when filling out a form and moving from one page to the other, but without submitting the results until the end.

> Vanilla js is unstructured.

Functions, classes, modules... everything is available to organize code. The mess some programmers make can be unstructured, but that's the case with any paradigm and yes, we've seen that with "modern" JS frameworks too. Spaghetti mess, lasagna mess, components mess or whatever pasta mess.

> I mean temporary state

What is the problem here ? It's as temporary as you need it to be.

Temporary state does not need need to be sent to the server, it can be managed in localstorage

I think the churn and misery of front end development is the inevitable result of 30 years of path dependence on technologies that were either substandard to begin with (javascript, css) or were never designed for what they're used for (html, css).

> I am never going back.

For some reason, it sounds like someone being held against their will, which is exactly how I feel about it too

I must be a masochist because I love FE frameworks. I love learning them and comparing them. I love how they are changing all the time and things are always improving somehow. What was great 10 years ago now are ridiculous to think about, What is great now will be completely forgotten in a couple years time. It's beautiful and maddening at the same time.

My favorite stack right now is Astro + SolidJS. Maybe it'll change next week. Who knows?

I don't know if you're a masochist, but I bet you aren't writing large apps. At work, the last thing I want is the technology I'm using to be obsolete in two months.

At my day job, we use something called ClickUp for task tracking. Watching the UI elements load one at a time reminds me of those greybeard stories about using vi over 300 baud modems. ClickUp is supposed to be productivity software.

HTMX pretty much enforces a 'one user action, one HTTP request, one HTTP response' pattern, which is necessary for a usable UX for users who can't see the data centre from their office window.

Like the article's writer, I remember the Netscape days and when JS came into existence. I was only a kid back then, like 9 years old, and was _just_ getting into coding in C and playing around with HTML/CSS. The results I produced, as you might have imagined, were akin to the results a toddler would produce given a wet loaf of bread to play with: mess everywhere.

Anyway, back then the HTML was simple (but it was tables and spacer GIFs ha ha!) and the CSS even simpler. Now it's just such a chaotic mess that people actually think Web Assembley is a good idea; as if somehow they've invented something new: the sandbox and the machine code. Like running a process at the OS level and making _that_ better, more secure, etc. wasn't the right path.

HTMLx is as close to the UI as I'll come. Everything else is an absolute headache to get into.

this ... multiplied by the high exposure of front end devs to client side requests for bells and whistles and the web studio demands on throughput

Reply on news.ycombinator.com