Live data from Hacker News

The Frontend Treadmill

polotek.net

631–640 of 722 posts

Re: The Frontend Treadmill

#631
post #477

Earlier quoted context omitted.

Alternatively: you can listen to audio while commuting or driving or cleaning or working out. I love audio for higher level things and to get an overview of the topic. Then text to dive into the details.

Another big driver to move from text to video: It is easier to monetise video via YouTube compared to a blog. People with millions of subscriptions on YouTube aren't creating FE learning material out of the goodness of their hearts; it is a big business. Also, video is almost always lower information density compared to text, so it is easier for your net to capture more customers.

I think you nailed it.

Another example of advertising destroying the world.

Re: The Frontend Treadmill

#632
post #436

I had this same mindset when React started gaining popularity. "Vanilla JS all the way". Then I saw the power of React, and fell in love with it. Then I landed a position that uses jQuery and Vanilla JS for everything a few years later... and oh my. It's absolutely awful. I know, I know, vanilla JS is most likely going to work in 5+ years as opposed to the React codebase, but damn. Wretched.

> but damn. Wretched I am curious. I know no React. I am neck deep in vanilla TS (not JS, small mercies) What is "Wretched"? My needs are simple (nobody at my org gives a single care about beautiful pages, it is an interface to an industrial process - big, feature-full interface, but not public nor a selling point)

For simple interfaces, vanilla is preferable, of course. But when you're working with mostly dynamic content and huge datasets, it really is a nightmare compared to using something like React.

With vanilla, it just takes more effort to build things. A file could easily become 2,000+ LOC.

Re: The Frontend Treadmill

#633
post #145

> Whatever framework you choose will be obsolete in 5 years. I am predominantly not a frontend dev, but when I do do frontend work, (and I don't avoid it by any means,) I have been using React for the past... 10 years now? And while some sentiment has been moving towards Svelte, by the time Svelte overtakes React, it will have been in production for just as long probably. And Angular might eventually run out of steam…

Yeah but we also got lucky there - like picking the right altcoin. React was just one of many then, and the rest all crumbled. And like OPs said, modern react is quite different than it was 10 years ago

> React was just one of many then, and the rest all crumbled.

Luck played a role, but if you were well versed in the ecosystem at the time (read: worked professionally in more than one framework), the others all had well known trajectories, limitations, or issues. Angular was just fine; Knockout was eaten by Angular. Ember was way too rigid and magical. jQuery was great but not a framework, more like a lodash. Backbone was really cool but incomplete and didn't help enough. In a way its the best one to compare too, because React was also minimal, but not incomplete - instead the part it did, it did better than you would on your own, then let you do whatever you want with everything else - I think they marked as "The V in MVC" at the time. It was both really powerful, simple, and easy to pick up especially if you were using a lot of jQuery or vanilla js at the time. Its the only one since jQuery that felt like it was simply adding useful stuff, and not taking anything away; I wasn't at all surprised to see it stick as well as jQuery, and for the others to fade. You'd be lucky to outright choose it out of ignorance.

Re: The Frontend Treadmill

#634

I love it when people phrase this as a frontend problem. It's not a frontend problem. It's just a "it's a huge ecosystem with new players" problem. I've seen this in Java 15 years ago when it was the front of innovation (I can name dozens of frameworks, and a half dozen build systems coming out in as many years). React 17-18 is quite a minor change then perl 5->6 or python 2->3 For backend instead of "let's use this…

Anecdotal: I agree because everywhere I have worked were backend-senior heavy -- they think frontend is easy and not worth touching, and they are the ones who makes decisions on "the next shiny things" for backend things. In my last job, databse migrations happened twice in just two years and we spent a total of one year of engineering time on it -- every single table, not just some non-critical ones. When things broke or when upper management was asking why thigns were so slow, they just blamed the front-end learning engineers for not being experienced enough.

Re: The Frontend Treadmill

#635

Earlier quoted context omitted.

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.

it was 10 minutes for me, too. No rehearsing. I don't know what you are going on about

Re: The Frontend Treadmill

#636

Earlier quoted context omitted.

If it's a 5 year old project, you probably shouldn't be building it with the current versions of tools. You need to pin your dependencies and use the same versions of the tools as before. It'd be the same thing with libraries if you didn't have a lockfile. Your development tools need one too.

> If it's a 5 year old project, you probably shouldn't be building it with the current versions of tools. Bold of you to assume I have worked in React for this long and somehow didn't know about this brittle solution to a problem which shouldn't have existed in the first place. How does your solution handle packages that no longer exist? Let me guess, we back up the packages? Okay, so these packages don't run on new…

wait, what package does no longer exist? is it something that has been unpublished from NPM?

Re: The Frontend Treadmill

#637

The counterpoint is that if you don’t adopt a framework you end up with a “framework” you built yourselves that people outside your team don’t understand, is generally poorly documented and needs constant work to add features existing frameworks already have. There are common features needed on the FE and common problems to solve, why not at least start with something instead of nothing?

I am not sure this is true . As I wrote elsewhere, almost everyone wants a web app or thinks that they have a web app, but usually it is just a dynamic website. You do not need to build up a framework to have a dynamic website.

"everyone" and "usually" are doing a lot of work here

Re: The Frontend Treadmill

#638

Earlier quoted context omitted.

Can you help me understand how this relates to my comment? We’re talking about what skills make you more marketable.

I replied to the wrong comment! Sorry, I can no longer change it.

Ha! All good. Been there myself.

Re: The Frontend Treadmill

#639

Earlier quoted context omitted.

React today looks very different from React from 10 years ago. Easily as different as being a different framework. So, there is some nuance, but the logic isn't dead quite yet.

As a daily React user for 10 years, and having used Ember, Angular, and several backend frameworks, I really don't agree. Hooks were the only meaningful change I can think of, and they took me about a day of real effort to grok, and a week to begin using well - in my existing React codebases no less. The primary way React works is unchanged since the very first day I learned it. It and SQL are probably the oldest too…

By a similar argument, most frameworks are the same, most JS package upgrades are the same, etc, etc.

It's still small incompatibilities adding up. It's still work.

Re: The Frontend Treadmill

#640
post #145

> Whatever framework you choose will be obsolete in 5 years. I am predominantly not a frontend dev, but when I do do frontend work, (and I don't avoid it by any means,) I have been using React for the past... 10 years now? And while some sentiment has been moving towards Svelte, by the time Svelte overtakes React, it will have been in production for just as long probably. And Angular might eventually run out of steam…

> And Angular might eventually run out of steam, but it's been around even longer than React, if you want to count the Angular1 and Angular2+ days together. I think this is true but also misses some aspects. Take Angular as an example. Angular1 and 2 cannot be compared at all, they were basically nothing alike except for the name. This burned many developers. But Angular itself is also changing quite drastically. Not…

New Angular versions lose support so fast that they are already highlighted as risks in our TLM tracker on the first day they are released!
Post reply on HN