Live data from Hacker News

The Frontend Treadmill

polotek.net

441–450 of 722 posts

Re: The Frontend Treadmill

#441
post #79

I have recently been doing some upgrades to the build system for our FE code to swap out yarn for pnpm. I’m normally a backend engineer, but I’ve spent plenty of time in the JS mines. The most frustrating thing about dipping in to the FE is that it seems like literally everything is deprecated . Oh, you used the apollo CLI in 2022? Bam, deprecated, go learn how to use graphql-client or whatever, which has a totally d…

This is why I have been so pumped for LiveView. It just removes so much javascript from the equation

And when you need to use JS, you can do so in a clean and controllable way.

Using Liveview to mount and unmount custom vue components can give you an extremely nice workflow, where you can just treat a complex select (akin to select2) as another type of input

Be sure to check out surface-ui. Marlus is a great guy, and surface really feels like the missing piece of liveview

https://surface-ui.org/

Re: The Frontend Treadmill

#442
post #20

Earlier quoted context omitted.

No separation between backend and front end is hard. I’m not good at front end, and we don’t have a designer. I’m miles better on backend though and other team members are more talented than me for front end design.

You would probably be decent at frontend if you did it at least 20% of the time. Obviously you can't be an expert at everything, but there is enormous value in being able to work on most things end to end instead of having to handoff every time.

I do it about 40% of the time - I'm just straight up not good at it, which is okay. I can get by, but it would be better for the company for somebody else to be doing it. Specialization can be good!

Re: The Frontend Treadmill

#443

Giving up on that treadmill after investing 3 insanely intense years consuming everything about it was the best thing I ever did. Now I write elixir (phoenix liveview), sometimes I write javascript (phoenix hooks), sometimes that javascript uses Alpine. Zero pain. I have never felt more vindicated understanding HTTP, Hypermedia, and HATEOAS than I have in the last three years.

I've only used Elixir/Phoenix as the backend with Elm as the frontend. If you're familiar with that, can you TL;DR what Phoenix Liveview does differently than a Phoenix/Elm/GraphQL stack?

Liveview nearly eliminates the boundary between backend and frontend. Your forms, inputs, outputs, whatever, just become another GenServer with a few special callbacks. You no longer have to worry about an API and syncing data from client to server. The transport layer becomes invisible

Re: The Frontend Treadmill

#444
post #20

Earlier quoted context omitted.

No separation between backend and front end is hard. I’m not good at front end, and we don’t have a designer. I’m miles better on backend though and other team members are more talented than me for front end design.

Design shouldn't be part of front end engineering - there is a reason there is a separate role for that, designer.

Yeah I agree, but we don't have a designer so what am I to do? I think I'm good at the frontend engineering as in breaking down component structure, passing data around etc. but I can't make something look good enough to meet my own standards.

Re: The Frontend Treadmill

#445

Earlier quoted context omitted.

E.g. react-router was ready 5990 commits ago. It is a grift, they keep rewriting it and reengineering the API over and over and over again just to be able to sell more training. Look at wouter for what is possible if your motivation isn't selling training material. It was written and left alone, it works just as well, it's stable and doesn't change for no reason.

Do you know anyone who bought courses on react-router? The documentation is right there for free.

[flagged]

Re: The Frontend Treadmill

#446

Earlier quoted context omitted.

How's your Create React App support in 2025? Are you still keeping your app on React 15?

It takes ten minutes to switch from CRA to Vite.

I think that's only if you've rehearsed it several times. Although now that I think about it, you will probably have to do it multiple times, so once you get good at it, that may be a reasonable estimate.

Re: The Frontend Treadmill

#447
I've been writing UX code professionally since the late 90's and for many years, I have led teams that build relatively complex UX software products at companies you've surely heard of.

It took me about about 5 years before I began to realize no one I had met, had any idea how to do this work in a way that wasn't horrible.

I held out hope, and thought maybe those other super-smarty-pants folks over there had it all figured out.

It took another 10 years to figure out that they most definitely did not have anything figured out at all. Functional weanies, OO nerds, Imperative Prima donnas. No one. Has GUI figured out. Not Apple, Not MS, Not Linux. No One.

I've worked professionally in every language, every framework, every paradigm. I've tried it all.

Writing Graphical User Interfaces is HARD.

The problem is that the problem is HARD.

Graphical User Interfaces (for anything reasonably sophisticated) represent broad and deep, hierarchical, tree-like (or graph-like) projections of large amounts of domain information PLUS some amount of administrative debris.

Changing any state of any node in these large and complex data structures can and often should cause some other node in some faraway sub-branch to instantaneously be updated.

Sometimes, that node is on someone else's computer. Almost always, there's a replicated, similar, but different version of that information on a server somewhere that really must be kept in sync.

The problem is made exponentially more complex when we just drop in some little multi-user, real-time update stories.

This thread is a great example of people shitting on the whole field, and yet... Not one person has figured out how to make front-end development not suck.

The problem appears to be deceptively simple on the surface, and like those sirens, it calls out to weary sailors, only to leave them shipwrecked on the shore.

Funny enough, it turns out that Text-based User Interfaces (TUI's) are far more expressive and exponentially easier to author and maintain.

They just have the little, teeny problem of being a sheer cliff face that users must ascend in order to get anything useful at all.

It's my bet, that the world will be saved by some mixture of Text and Graphical UX that is primarily rooted in Text, but enhanced by graphics, rather than the other way around.

This whole LLM thing looks kind of interesting on that front.

I suspect we'll all look back on the last 30 years with contempt and remorse at all the wasted time and energy we've put into this mess that we've created that is called, "Graphical Applications."

Feel free to rant on about how shitty everything is, but just remember that at least one person out here in the ether knows that your solution either doesn't exist (most likely) or is even worse.

Re: The Frontend Treadmill

#448

Earlier quoted context omitted.

I'm only recently getting into some of the dev influencer stuff (and enjoying watching some!), I've discovered Primeagen and Theo but that's about it. Are you willing to name some names? I am trying to still form my mental model about these people and what I should pay attention to and what I should ignore.

Prime is almost an anti-influencer. He promotes not adding dependencies more often than not. He's the guy making fun of the Ai craze, while also genuinely reviewing the recent releases and saying people should just learn to code instead. I really wouldn't put him in this general category of fe influencers discussed here.

Meanwhile Primagen: " I Am Using Cursor - CURSOR FOUNDER TEACHES ME CURSOR!!!!!!! #ad "

Re: The Frontend Treadmill

#449

Earlier quoted context omitted.

And the craziest part is that it is built on top of JS/HTML which is an extremely stable technology at heart. 15 years ago I wrote a small (5KLOC) vanilla JS webapp that is still in daily use by around 10 people without a single line changed. It held up better then my Win32 applications! Almost all of the front end churn is simply a political/organizational failure.

This stability does mean that old React (or Knockout, or whatever) applications will still work just fine for the end users, likewise without a single line changed. The instability is on the tooling side (and peer deps). Getting back into a project that uses Broccoli and Bower is a nightmare. And that was just a handful of years ago. You have to become a detective, finding what combination of package versions and Hom…

> This stability does mean that old React (or Knockout, or whatever) applications will still work just fine for the end users, likewise without a single line changed.

Not in the current enterprise cyberops environment of needing to pass dependency security scans at all times.

Re: The Frontend Treadmill

#450
I think this issue will slow down as LLMs become more prominent. I find myself being naturally dissuaded from the "shiny, new thing" because it means my LLM won't have a deep set of materials to draw from.

Writing in Bevy was really hard because it was a niche language that has breaking changes every three months.

Writing in Svelte has been decent/good, but LLMs constantly prefer using v4's syntax rather than v5's runes -- even with Cursor rules and reminders.

At some point I think the tools will become so overwhelmingly part of my workflow that I'll prefer sticking with the old rather than moving to the new and losing access to well-written LLM code code.

Post reply on HN