Live data from Hacker News

The Frontend Treadmill

polotek.net

321–330 of 722 posts

Re: The Frontend Treadmill

#321

Earlier quoted context omitted.

Class components and HOCs aren’t deprecated though.

They're very much not "best practices", and will be deprecated soon (if they're not already).

That's not true (the deprecation part, anyway) and I know of at least one React team member who has spoken publicly to that fact.

Re: The Frontend Treadmill

#322

Earlier quoted context omitted.

I called out a grifter.

And what have you put out into the world?

I push back on stuff like this so developers who feel the feet on their throat from this culture can have some confidence to nudge the boot off.

There goes my hero: https://youtu.be/EqWRaAF6_WY

Re: The Frontend Treadmill

#323

Earlier quoted context omitted.

> That people like video formats isn't really surprising to me since it's everywhere That’s because those “people” are either larping students or kids that want to become programmers. I have never in my 10 year career met a person who said “yeah, I learn my craft from Fireship videos”.

I've learned most of what I know about database internals from MCU lecture course on YouTube. It's great.

Marvel cinematic university?

Re: The Frontend Treadmill

#324

Earlier quoted context omitted.

> It’s just nuts to me the degree to which FE development as a whole seems to embrace the breaking change, the deprecation, etc. I’m amazed at how much of this is driven by the FE influencers. The FE world has embraced social media, YouTube, and even Twitch to a degree that I haven’t seen in other domains. Influencers in these areas need to have a constant stream of fresh material to stay relevant, so they’re always…

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.

Primeagen and Theo is pure brain rot.

Re: The Frontend Treadmill

#325

> 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,…

I've been in the market for 30 years, had some of the best jobs on earth doing FE, and only did my first React project last year. Maybe I'm an anomaly but I never felt that not knowing React has been a problem. "table stakes" is too strong a phrase.

To be fair, "30 years of experience" likely opens more doors than any particular skill listed on your CV - that doesn't reflect the way that a majority of junior/mid-level devs need to present their abilities, where pattern-matching is an unfortunate norm, particularly when there are orders of magnitude more applicants than open roles.

Re: The Frontend Treadmill

#327

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…

Hi there - I work at Apollo and I'd be happy to help you migrate off our old CLI. That utility was sort of a hodgepodge of tools that we ended up either replatforming to our `rover` CLI or, in the case of code generation, recommending that folks use GraphQL Code Generator. It's a testament to that utility's sprawl that I can't guess your use case just by your name-drop of it. I realize the irony in my saying that since it sort of plays into this narrative, but FWIW all the functionality (and then some) of `apollo` is still actively maintained, just not in that particular codebase or form factor. Let me know if there's anything I can do to assist.

FWIW Apollo Client is actively maintained, has a lot of new features, and is preparing a v4 release (currently in Alpha). We'll be celebrating 10 years next year :)

Re: The Frontend Treadmill

#328

Earlier quoted context omitted.

> It’s just nuts to me the degree to which FE development as a whole seems to embrace the breaking change, the deprecation, etc. I’m amazed at how much of this is driven by the FE influencers. The FE world has embraced social media, YouTube, and even Twitch to a degree that I haven’t seen in other domains. Influencers in these areas need to have a constant stream of fresh material to stay relevant, so they’re always…

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.

Not an influencer but: Casey Muratori is great.

He's actually the opposite of the "trendsetter" kind that is being criticized here, and is more of an educator with lots of experience in both education and business.

Re: The Frontend Treadmill

#329

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.

[deleted]

Re: The Frontend Treadmill

#330
post #251

Earlier quoted context omitted.

Well, that's just moving the goal posts. I never said you wouldn't have to do any maintenance at all, just that the floor doesn't just fall from under everyone every 5 years. Even outside of frontend, most ecosystems move fast enough that projects from 10 years ago would be in pretty bad shape. That's long enough that even many C/C++ projects will not compile, if nothing else, as a result of improvements to compilers…

I don't think it's moving the goal posts. It's a very reasonable thing to ask. I have Go projects that are now 10 years old that require zero maintenance on my part. I also do frontend as my day job, and it's extremely hard to get any old react project to work with current tooling. The migration work basically amounts to a total rewrite and that's the issue with react. Sure if you were using just react that is okay,…

I don't really disagree that there is a lot of churn in frontend, but a lot of that comes down to simply picking up too many dependencies, a problem that isn't really that hard to avoid by simply not doing that. I have indeed had large projects where the list of direct dependencies was about a dozen, because if you are more judicious about dependencies, it's not so bad.

Go is a great example. Once Go hit 1.0, it gained very strong compatibility guarantees. Go has two properties that make it much better in terms of ecosystem stability than JS was:

- The Go standard library. For a long time JS lacked very basic functionality in its standard library. Go has a very nice standard library that not only covers essential algorithms and data structures, but also standard I/O interfaces, implementations of popular protocols and file formats, and a full cryptography suite. 10 years ago, JavaScript lacked much of this, so you often had to "roll your own". Today JS has standard modules, WebCrypto, the File System API, IndexedDB, bigint, ES Maps and Sets, and more. The problem is much alleviated.

- Go has an ethos of minimal dependencies, a la the famous Go proverb, "A little copying is better than a little dependency." JavaScript had virtually the opposite attitude; they were pushing for making every small thing a module. This was a terrible idea, and it has led to the unfortunate reality that your dependency trees in Node.JS grow uncontrollably. This has been somewhat alleviated, though there are still many projects with out-of-control module trees.

Mind you also, that React prior to v15 was also considered pre-1.0; the last relatively big transition (to ES classes) happened in v13, which was actually v0.13 at the time.

But come on. The quote I took issue with was:

> Whatever framework you choose will be obsolete in 5 years.

This is an exaggeration. Undoutedly the JS ecosystem is not as stable as the Go one, but I don't think dropping all frameworks because the ecosystem moves kind of fast is the right answer. There's a measure in the middle.

Post reply on HN