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

191–200 of 722 posts

Re: The Frontend Treadmill

#191

Post by wonger_ »

upghost wrote: post #157

The article mentions "web fundamentals" and "getting back to the fundamentals". Sounds great! Would anyone care to have a conversation about what this means? Like does the author mean DOM manipulation or TCP stack? I feel like this is pretty broad and even though I've been doing full stack for a bit now I'm suddenly not sure if I know the fundamentals.

I think "web fundamentals" here might mean DOM manipulation, browser-native APIs, default form inputs. Stuff like and document.querySelector() and appendChild(), which are often abstracted over or replaced with frameworks.

Re: The Frontend Treadmill

#192

Post by mejutoco »

gryn wrote: post #109
mangodrunk wrote: post #45

Earlier quoted context omitted.

Well said. The BE / FE split has been a really bad experiment. It has exasperated the issue where the FE is overly complex because there are people on a FE team, so they toil away and just add complexity. It is also problematic that we have so many people who only know web development and nothing else.

As someone who's been on teams/products that did away with the front/back separation back in the php era I think that's a terrible idea. When things go wrong, which they will given enough time, size and complexity, the blast radius is much bigger. I still remember trying to change an onboarding page on a website only to find code with goto statements that jump to places that does db calls, messes with code for c proc…

I wonder what you think of components. Back in the day it was heresy to mix css html and js. Everything was separated. Nowadays a component mixes them all.

In a way, it is exactly the example opposite of what you mention.

Re: The Frontend Treadmill

#193

Post by koakuma-chan »

locallost wrote: post #135
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…

decides to swap out a working package manager for another for no apparent reason "Why do JS people keep doing something new for no apparent reason?"

I'd gladly swap out any piece of tooling if it's written in JavaScript.

Re: The Frontend Treadmill

#194

Post by hajile »

breadwinner wrote: post #151

> Whatever framework you choose will be obsolete in 5 years. The mistake here is the assumption that you need a "framework". I challenge this notion. What does code that does not use a heavy framework look like? It is very maintainable and easy to use and will not become obsolete. Here's an example: https://github.com/wisercoder/eureka/tree/master/webapp/Clie... It uses two 500-line libraries, hardly a "framework". O…

VanillaJS is a worse solution. When the JS framework benchmark first came out, VanillaJS was the fastest. After some of the vdom frameworks came out (especially InfernoJS), VanillaJS was slower.

How did they make VanillaJS faster? They studied the output code paths of InfernoJS and copied them. Each time InfernoJS would release new, faster versions, they'd backport those optimizations into the VanillaJS. Then SolidJS and Svelte came out and it copied them.

By the time it was done, the VanillaJS code was fast, but not very readable and definitely NOT the type of code a human would write. Additionally, each new piece being hand-written means each is a brand new chance to miss little implementation details that lead to subtle bugs and memory leaks. As your site grows, you'll also develop bugs from accidentally stomping on someone else's piece of the DOM unless you add all the overhead/complexity of shadow DOM.

pReact (or something similar if it exists) is a much better type of solution IMO. Here's a link to the whole source code minified.

https://esm.sh/preact@10.26.4/es2022/preact.mjs

It's not even a whole page on my laptop screen, but it will be faster than an average dev's VanillaJS code 95% of the time. It won't have those potential implementation bugs. It will scale to many components and devs effortlessly. It also provides clean, tested ways to add other features your project may need in safe ways.

Re: The Frontend Treadmill

#195

Post by divan »

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…

The worst thing is that it's a cultural aspect. This deprecation and breaking stuff hell is a result of millions of micro-choices. "Why not rename MultiselectDropdown into MultiSelectButtonDropdown! And maybe replace the API of that component to a completely new one! Sounds like a cool idea!". Thousands of person-hours are spent daily for fixing results of such 'extremely important'™ breaking changes.

There is simply no culture of understanding the staggering costs of breaking APIs. This is especially frustrating after working for a decade with Go, that has backwards compatibility promise. Which somehow affects Go library developers stance on compaitbility and breaking things. The code written 10 years ago perfectly compiles and work on latest Go version, and it's such a wonderful experience.

One of the ways of escaping this JS/web hell for me was switching to Flutter. It worked great, most of the web-stack accidental complexity was happily forgotten. But this culture of "breaking package is fine" creeps in into Dart ecosystem as well, and it's annoying as hell.

Re: The Frontend Treadmill

#196

Post by Jcampuzano2 »

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

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. Especially so when it comes to things like consulting work, contracting, etc. Having worked alongside the people who do the hiring or make the decision as to whether to bring somebody in for an interview at all in big consulting firms, they basically automatically disqualify anybody who doesn't already know the stack they prefer to use or that the client they are currently hiring somebody for uses. And this is including technical architects, so this isn't even just an issue of non-tech aligned hiring people. They simply don't want anybody to have to ramp up on the tech itself regardless of skill.

For these types of roles it is very important to be up to date if you want to stay hirable, or the hiring manager will just throw your resume in the trash before it even gets in front of an engineer who can evaluate your skills without the buzzwords.

Re: The Frontend Treadmill

#197

Post by coffeebeqn »

8n4vidtmkvmk wrote: post #156
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?

No, we're past pnpm and on to bun now

Sorry, everyone’s on pyarn now and next month we’re deprecating that for pbun and then starting from scratch with taquito when that doesn’t solve all our perceived problems

Re: The Frontend Treadmill

#198

Post by ajmurmann »

schindlabua wrote: post #110
mplanchard wrote: post #92

Earlier quoted context omitted.

I agree you can avoid it with care, but I do think it's a JavaScript problem, at least moreso than in other languages. The culture is one of acceptance of churn. It seems like everything from minor libraries to major frameworks is much more likely to introduce a breaking change in JS than in Rust, C++, or even python. I've never written any emacs lisp that I had to change when upgrading emacs, and the third-party lib…

And I think the Javascript problem exists because frontend/UI is just a very complicated domain, in the sense that frontend is a big messy ball of side effects. If you've been around and saw the web grow up, and saw all the new ideas all those libraries brought to the table (jQuery deferreds becoming async/await, 960 grid slowly morphing into flexbox and css grid, etc etc) then all the breaking changes make sense, we…

It seems that in addition to the issue were some things were actually tedious to do, there has also always been a drive to wow users (or really other devs?) by doing something that pushes the boundaries of what's possible. Once someone has done it, everyone is expected to do it and now work is tedious again. A simple example is how back in 2009/10 everyone was all excited about rounded corners. You had to cut all these assets and got a more complex DOM but it became table stakes. So CSS got an attribute for this. Then we needed fancy grids everywhere and fourteenth elements on mobile which was tedious till frameworks did some of it. I think the wow-treadmill doesn't exist like this on the backend because nobody sees it. The closest equivalent is scaling your architecture for a level that your app will never need.

Re: The Frontend Treadmill

#199

Post by emseetech »

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…

Ironic that FE dev is built on HTML and CSS, two specs that are so painfully backwards compatible that the original Space Jam website from 1996 still works.

A web app written with HTML and CSS and a sprinkling of no-build Javascript will likely work as intended in 30 years.

Re: The Frontend Treadmill

#200

Post by wiseowise »

divan wrote: post #195
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…

The worst thing is that it's a cultural aspect. This deprecation and breaking stuff hell is a result of millions of micro-choices. "Why not rename MultiselectDropdown into MultiSelectButtonDropdown! And maybe replace the API of that component to a completely new one! Sounds like a cool idea!". Thousands of person-hours are spent daily for fixing results of such 'extremely important'™ breaking changes. There is simply…

> But this culture of "breaking package is fine" creeps in into Dart ecosystem as well, and it's annoying as hell.

It’s almost like this has nothing to do with technology and is more result of a barrier of entry that is one step about nocode solution.

Post reply on HN