Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Frontend Treadmill

polotek.net

Post reply on HN
Print view View original

591–600 of 722 posts

Re: The Frontend Treadmill

#591

Post by xigency »

skydhash wrote: post #353
hajile wrote: post #93

Earlier quoted context omitted.

There's a disconnect between how a computer wants to do things and how a human wants to do things. This disconnect isn't so noticeable on the backend where the problems are generally related to scaling (as there isn't a generalized solution). On the frontend though, this disconnect is everything. This leads to a tension between devs wanting to abstract and everything constantly breaking the abstraction rules. This le…

> This leads to a tension between devs wanting to abstract and everything constantly breaking the abstraction rules. This exists everywhere. But the churn only exists in the NPM section of the JavaScript world. QT, SDL, GTK, Cocoa have very stable paradigms to do UI. Even the DOM api is stable. But in the NPM world, nobody wants to actually stick to an API, instead they insists on supporting edge cases that should ac…

Like a challenge to write better code that is still bad enough to throw away as soon as possible, I think there's something to scripting that feels enticingly ephemeral.

Re: The Frontend Treadmill

#592

Post by le-mark »

theknarf wrote: post #583
dpcx wrote: post #355

Earlier quoted context omitted.

React has been around for 11 years. The amount of stuff that's online that tells you to do something with it one way when the react devs tell you to do it another is _astonishing_. And that's just from the last few years. Or take webpack that's been around for 13 years. The way things are set up even within the last few years have changed dramatically. If Apache configs moved as much as these systems did, no one woul…

No one is using Apache... Almost everyone moved to Nginx years ago xD

The configs are very similar though, the reasons for the move were technical and performance, for whatever that’s worth.

Re: The Frontend Treadmill

#593

Post by makingstuffs »

koreth1 wrote: post #463
ewzimm wrote: post #171

Earlier quoted context omitted.

That's fascinating, and I had no idea web dev influencers were so big. I checked, and there really are people with millions of followers doing development. Personally, the idea of learning anything related to coding through a video is extremely frustrating. It's a text medium. I want to look at things, take time, think it over, compare code, follow references, look up functions. That people like video formats isn't r…

> That people like video formats isn't really surprising to me since it's everywhere, but I still don't fully understand the appeal. Me either, but I have a hunch about why. Are you a fast reader? I am, at least compared to the population at large. And one of the reasons I can't stand video as a format for learning about coding topics is that it is so frustratingly slow compared to my reading speed. To get anywhere c…

That’s a really interesting take. I say that as I’m the opposite — a slow reader — and I, too, cannot stand learning via video.

I’m by no means a weak reader, I love reading and do so often. I just find myself re-reading complex sections to ensure that I understand 100%.

I also like to be able to read something and then follow it on a train of thought. For example, if a post/article says that X causes Y because of Z I want to find out why Z causes it. What causes Z to be etc.

With a video I find this sort of learning to be inefficient and less effective while also making the whole experience a bit rigid. I also find that videos tend to leave out less glamorous details as they don’t video well if that makes sense

Re: The Frontend Treadmill

#594

Post by canyonero »

I think it’s reasonable for the author to feel like Frontend is a treadmill. It can at times without a doubt be tiring. It certainly was moving much, much faster in the 2010s (although, I think it started to cool down in the 2020s)

I don’t think this specific problem targeted at Frontend or Frontend frameworks is necessarily useful other than to vent. It seems this can be attributed as an effect of swelling technology communities. Frontend has been a community with explosions of ideas, high levels of participation and enthusiasm coupled with opportunities for notoriety and wealth.

One could argue that AI is currently experiencing a similar phenomenon as Frontend did in the 2010s. If it follows a similar trajectory, we’ll be seeing articles about AI treadmills.

Re: The Frontend Treadmill

#595

Post by le-mark »

nine_k wrote: post #292
bob1029 wrote: post #80

Earlier quoted context omitted.

> no separation between backend and frontend folks in the company. This is the biggest gain available anywhere. When you have one engineer who is empowered to write SQL specifically crafted to pull the exact columns required to SSR a web view (which they are also responsible for), you don't need to spend a single second thinking about APIs or ORMs or whatever. You just need to know SQL and modern vanilla HTML/CSS/JS.…

Plain HTML and plain CSS (well, maybe with SASS) are pretty great. Plain JS loses much to plain Typescript though, to my mind.

Is there a way to use typescript without pulling in all of npm? That’s the deal breaker for me, maybe others as well.

Re: The Frontend Treadmill

#596

Post by evrybdygonsrfin »

genuine_smiles wrote: post #48
fragmede wrote: post #33

Earlier quoted context omitted.

Wait, we're supposed to use pnpm now? What happened to yarn? What's wrong with npm? I stop paying attention for six months and even the installer has changed. What's an npx?

Yarn is still great. npm is ok. pnpm is a little faster than Yarn but has less features.

Hardly a deal-breaker; presumably I can just pipe the output to less.

Re: The Frontend Treadmill

#597

Post by speleding »

localghost3000 wrote: post #148

> And if you’re an engineer, you will be able to retain much higher market value over time if you dig into and understand core web technologies Been working in FE for nearly 20 years and lived through several major paradigm shifts. I think I am qualified to have an opinion here: I definitely think that you will be a more well-rounded engineer if you know all the core web tech. So strongly agree there. I am skeptical,…

Or..or..or.. don't use a framework!

You can do so much with HTML5 + CSS + Vanilla JS nowadays. I think the default "let's start by picking a framework" is often wrong, unless you know from the start this is going to be a large SPA. Yes, you'll write a little bit more boilerplate for stuff you get for free from a framework, but it will pay itself back in the long run because there is no upgrade treadmill.

Re: The Frontend Treadmill

#598

Post by zaphar »

apsurd wrote: post #565
nullpoint420 wrote: post #408

Earlier quoted context omitted.

> mostly with web standards IMO, the pain from "mostly" starts to show when integrating React Router v6 with legacy frameworks and applications. I'm sure if you go all in on React Router v6 it's great. At my $DAYJOB we are migrating to Remix w/ GraphQL Federation. It's been a pain. Especially because we haven't finished any of these migrations: * ExtJS -> JQuery * JQuery -> React class components * React class compon…

your last note that adds not-invented-here abominations… if chasing endless frameworks of the month is bad, and building stuff in house is bad, then what do you propose to avoid making this mess?

Skip a couple framework versions and indeed entire frameworks. Maybe go a couple years before you "upgrade" to something else. It is entirely possible you could go as much as 5 or 10 years on something. You'll still have to evaluate and potentially mitigate some CVE's. But that could actually be less work and less aggravating.

Re: The Frontend Treadmill

#599

Post by tasuki »

jweir wrote: post #373

We use Elm for any complicated front end. Elm has not been updated in over five years.

People say "Elm is dead". Yes, and that's one of its many amazing features!

I'm not a frontend developer, but I'm always looking forward to writing frontend these days!

Re: The Frontend Treadmill

#600

Post by iainmerrick »

DidYaWipe wrote: post #509
tylerchurch wrote: post #493

Earlier quoted context omitted.

I always interpret “core” as “no libraries”. What can you do with just your browser and an HTML file? Poke through MDN and see what you find. Do you know about dialog? https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di... MutationObserver? https://developer.mozilla.org/en-US/docs/Web/API/MutationObs... URL? https://developer.mozilla.org/en-US/docs/Web/API/URL_API

Thanks! I looked at MutationObserver and wondered about the example: if (mutation.type === "childList") { console.log("A child node has been added or removed."); How can such changes occur to the DOM that aren't brought about by other code on the page? And if other code on the page brought them about, why didn't it also perform whatever the MutationObserver is doing? Anyway, not to get too mired in details... I've do…

How can such changes occur to the DOM that aren't brought about by other code on the page? And if other code on the page brought them about, why didn't it also perform whatever the MutationObserver is doing?

You're right, that approach would also work. But MutationObserver can be useful for decoupling, to reduce complexity -- you don't need to think about all the possible ways some part of the page could change, you just want to be able to say "if the contents of this div change, do this".

I used it in a recent project for layout animations. I needed to measure the size of a particular div that slides in and out, to position it correctly, so I added a MutationObserver to re-runs the calculation any time there are changes.

Is there a "next-level up" front-end layer that provides convenience functions but still isn't a bloated framework liable to be obsolete?

Well, pretty much all frameworks will claim to be that...!

I think some things you might find useful are:

- Polyfills. Just use standard browser APIs (which are getting really good these days) but use polyfills to ensure they work correctly/consistently across different browsers.

- Web components. I haven't used these myself, but as I understand it, it's a way of packaging JS modules so they can be used exactly like new HTML tags. So somebody could make a nice component for example. I've heard that Lit is a good library for developing web components, but it's not a framework in the sense that it will take control of your whole architecture.

- Vite. This bundles your HTML, scripts and assets -- you can develop your code in vanilla HTML and JS, and Vite will package it up neatly for publishing. It's really fast and reliable. Tons of frameworks are built on top of Vite, but you can go quite a long way just with Vite on its own (and there isn't any lock-in as its input is just HTML).

Post reply on HN