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

571–580 of 722 posts

Re: The Frontend Treadmill

#571

Post by austin-cheney »

DidYaWipe wrote: post #492
Jcampuzano2 wrote: post #196

Earlier quoted context omitted.

Knowing basic web technologies to a deep level are very important and highly valued, especially so at larger companies where they know that the framework itself is a minor detail for skilled engineers who can pick up and be productive in any framework in less than a weeks time, so I do think you can command high market value with very deep knowledge of the platform itself. However, that said I agree with you. Especia…

Lots of reference in these comments to "core" or basic Web technologies. What would you say they are? What's the highest-level thing that's still "core?"

The DOM, events, CSS, WCAG. If you want to get into TypeScript then just type and interface keywords. If you want to get into Node then it’s the library system in Nodes documentation. That is it.

I never mentioned build tools. You can write your own quickly.

Re: The Frontend Treadmill

#572

Post by austin-cheney »

DidYaWipe wrote: post #492
Jcampuzano2 wrote: post #196

Earlier quoted context omitted.

Knowing basic web technologies to a deep level are very important and highly valued, especially so at larger companies where they know that the framework itself is a minor detail for skilled engineers who can pick up and be productive in any framework in less than a weeks time, so I do think you can command high market value with very deep knowledge of the platform itself. However, that said I agree with you. Especia…

Lots of reference in these comments to "core" or basic Web technologies. What would you say they are? What's the highest-level thing that's still "core?"

The DOM, events, CSS, WCAG. If you want to get into TypeScript then just type and interface keywords. If you want to get into Node then it’s the library system in Nodes documentation. That is it.

Here is a practical example: https://github.com/prettydiff/wisdom/blob/master/performance...

I never mentioned build tools. You can write your own quickly, and you don’t need all the framework bullshit. That stuff is for insecure people and otherwise just slows you down.

Re: The Frontend Treadmill

#573

Post by admiralrohan »

The frontend space will surely change to accomodate AI.

We may go back to pre-framework days if we don't need that much complexity anymore. If we start to rely on AI Summaries we won't need complex interactions. Just beautiful charts to explain data.

Re: The Frontend Treadmill

#574

Post by edwinjm »

sfn42 wrote: post #569
johnfn wrote: post #513

Earlier quoted context omitted.

As a primarily frontend engineer who has "spent plenty of time in the Python mines", I feel exactly the same way. Oh my god, Python is a horrific mishmash of deprecated and impossible-to-upgrade libraries and dependencies. Honestly, I think it's significantly worse than the frontend - at least with the frontend, the scope of the damage is limited by TypeScript and the language limiting you to doing relatively sane th…

Well I've never worked much with python aside from using it for some math and ML classes in uni, but it's always been pretty close to JS near the bottom of my mental system programming language tier list. If you want to throw together some quick thing or toy project or whatever sure, knock yourself out. But I'll honestly never respect people who write large "serious" applications using Python or JS for their backend.…

JavaScript is perfectly capable to run on the backend. Many people/companies do it with great satisfaction.

Re: The Frontend Treadmill

#575

Post by grishka »

That's why I haven't even bothered getting into the atrocity that is modern frontend. I still build stuff mostly like it's 2007. In my projects I don't even have much of a frontend — most of the functionality works without any JavaScript whatsoever — but the JS that I do have has to contain exactly zero third-party runtime dependencies. I'm okay with self-contained third-party scripts like Leaflet for when I need to display a map, and I'm okay with build tools like TypeScript and PostCSS. But that's it really. I'm not having any of that abstraction-over-single-platform nonsense.

Re: The Frontend Treadmill

#576

Post by wruza »

sethammons wrote: post #561
johnfn wrote: post #513

Earlier quoted context omitted.

As a primarily frontend engineer who has "spent plenty of time in the Python mines", I feel exactly the same way. Oh my god, Python is a horrific mishmash of deprecated and impossible-to-upgrade libraries and dependencies. Honestly, I think it's significantly worse than the frontend - at least with the frontend, the scope of the damage is limited by TypeScript and the language limiting you to doing relatively sane th…

I am back at a python shop and (again) pushing, successfully, Go. Python is molasses for teams for all the reasons you state and more.

What does “molasses” mean here? Search says it’s “slow”, but that makes little sense.

Re: The Frontend Treadmill

#577

Post by rcarr »

Etheryte wrote: post #142
croes wrote: post #125

Earlier quoted context omitted.

Which version of react? Hooks or classes? Or whatever comes next.

You can still write class-based components in React, no problem. It might not be in vogue, but for the most part, you can still write React 18.x roughly the same way you wrote React 0.x.

You can but are people going to when the first thing you see upon opening the docs is a giant warning telling you not to?

https://react.dev/reference/react/Component

Re: The Frontend Treadmill

#578

Post by theknarf »

I think he have a good point, you shouldn't be switching frontend tech all the time. Focus on making a good product.

> If your product is still around in 5 years, you’re doing great and you should feel successful. But guess what? Whatever framework you choose will be obsolete in 5 years.

However I feel like this point isn't entirely correct. According to StateOfJs [1] React have been the most used frontend library for the last 8 years (which I think is how long the survey have been done). React Hooks which is the modern way of writing React components have been around for 7 years (since 2018).

React is definitely going to be around in 5 years, and most likely still going to be the most used frontend library. I also don't think Vue is going away in the next 5 years (Angular might however, they are loosing usage numbers year after year).

So really I think there is an argument to be made that you should just use React and move on.

[1] https://2024.stateofjs.com/en-US/libraries/front-end-framewo...

Re: The Frontend Treadmill

#579

Post by rcarr »

only-one1701 wrote: post #59
crab_galaxy wrote: post #34

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).

I have no idea why you are getting downvoted for this comment when there is literally a massive warning on the docs page for class components.

https://react.dev/reference/react/Component

Re: The Frontend Treadmill

#580

Post by wruza »

cxr wrote: post #295
mplanchard wrote: post #2

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…

> Meanwhile in JS it seems like you can’t go more than six months without having to rewrite something. And by "in JS", you really mean, "in NPM land". So long as folks keep remaining seemingly (almost willfully) ignorant of the source of their pain and/or running right back into the fire the next time the opportunity presents itself, that pain is going to continue. NPM sucks. It's not the way to do JS. Everyone who h…

Also by “npm land” you mean “react-webpack-based bloated build- and eco-systems”.

NPM sucks. It's not the way to do JS

${X}PM is absolutely the way to do $X. You can’t survive without the PM part. You just have to know cancer when you see it and call it out rather than praising.

Post reply on HN