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).
The Frontend Treadmill
321–330 of 722 posts
Re: The Frontend Treadmill
#322Earlier quoted context omitted.
I called out a grifter.
And what have you put out into the world?
There goes my hero: https://youtu.be/EqWRaAF6_WY
Re: The Frontend Treadmill
#323Earlier 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.
Re: The Frontend Treadmill
#324Earlier 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.
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.
Re: The Frontend Treadmill
#326Re: The Frontend Treadmill
#327I 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…
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
#328Earlier 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.
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
#329Earlier 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.
Re: The Frontend Treadmill
#330Earlier 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,…
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.