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

301–310 of 722 posts

Re: The Frontend Treadmill

#301

Post by jasode »

ewzimm wrote: post #171
Aurornis wrote: post #161

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…

That's fascinating, and I had no idea web dev influencers were so big. I checked, and there really are people with millions of followers doing development. Personally, the idea of learning anything related to coding through a video is extremely frustrating. It's a text medium. I want to look at things, take time, think it over, compare code, follow references, look up functions. That people like video formats isn't r…

>, the idea of learning anything related to coding through a video is extremely frustrating. It's a text medium. I want to look at things, take time, think it over, compare code, follow references, look up functions. That people like video formats isn't really surprising to me since it's everywhere, but I still don't fully understand the appeal.

I like (some) programming videos and I'll give my perspective as someone who learned 100% from books and 3-ring binders for old languages like C/C++/C#/Javascript/Python/bash/etc. (The 1980s Microsoft C Compiler manuals were 3-ring binders.)

The newer languages I learned with a hybrid of videos + traditional books would be HTML CSS, Apple Swift, and PyTorch with the latest AI toolkits and libraries.

The extra dimension that videos offer besides plain text is the live usage of IDE, tools, troubleshooting, etc. For me, watching a dynamic screen with a moving mouse cursor and voiceover seems to activate extra neurons moreso than just reading static text in a book.

There's also a lot of "activities in-between the coding" that's helpful such as seeing the programmer looking up something in various pages of documentation, scrolling around, navigating etc.

Another useful aspect that's underappreciated is seeing the mistakes the programmer makes during the video recording. E.g. the code doesn't compile because of invalid syntax. Or a config setting is wrong and he troubleshoots what's preventing it from working. In contrast, virtually all text books or blogs of coding are "perfect happy path" outcomes. But real-world programming is messy with broken intermediate states. A lot of videos show the messy steps to get to a working state.

The videos that are not that helpful would be the videos of C++ CppCon conference sessions where there are a bunch of static slides with bullet points and the speaker just reads them aloud word-for-word.

Although I learned C++ from textbooks, I found videos of Matt Godbolt showing tips & tricks of how to use his Compiler Explorer (http://godbolt.org) very helpful.

In summary, the artifacts of coding may be the text, but the activity of coding involves a lot more than just the text and that's why some videos can enhance learning.

Re: The Frontend Treadmill

#302

Post by lelandfe »

WorldMaker wrote: post #206
fridder wrote: post #85

Earlier quoted context omitted.

Basically we are in this scenario: https://xkcd.com/927/ Honestly though I think WASM might be the final state of the web.

WASM makes things worse because now "rewrite it in hip new frontend framework X" has more options. Tired of React? Try Blazor WASM (C#) or any of the exciting new Rust-based front ends or any of the up-and-comers in Swift, Go, Perl, Befunge, Intercal, and other favorite languages or flavors of the month. Dart's not just a thing for people installing Chrome Extensions, now you can use it in WASM almost like Father Goo…

FFI is new for me. Foreign function interface? https://en.wikipedia.org/wiki/Foreign_function_interface

> A foreign function interface (FFI) is a mechanism by which a program written in one programming language can call routines or make use of services written or compiled in another one

Nifty, will remember that.

Re: The Frontend Treadmill

#303

Post by proc0 »

mangodrunk wrote: post #45
antirez wrote: post #9

To jump off the treadmill is not using a fronted framework: at all, and not using a random one and not rewriting the code later. Server side rendering, JavaScript only when needed, no separation between backend and frontend folks in the company.

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.

It's not an experiment though. The divide is clear, you have a client application, and then server applications that the client talks to. This is even more true if you want a lot of interactivity. This line isn't going away anytime soon. There will always be an application that runs on the edge device or machine, and it needs to talk to some other application to store and retrieve data.

Re: The Frontend Treadmill

#304

Post by only-one1701 »

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

Mea culpa: they’re not being deprecated. But the existence of custom hooks removes the bulk of (if not all of) their utility, and make it much easier to reason about code and make your code well-typed.

Re: The Frontend Treadmill

#305

Post by jilles »

jchw wrote: 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…

I've been doing React for about 10 years. Just started playing with Svelte 5 a few days ago.

It's so simple to work with. Built a simple stock allocation app and what surprised me most was the bundle size... 9kb (gzip). That's better than any other framework I am aware of. That's even smaller than htmx which is somewhat "anti-js"

Re: The Frontend Treadmill

#306

Post by proc0 »

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.

He's missing the bigger picture, IMHO. Nobody goes back to fundamentals because the industry is not allowing the role to do that. FE engineers don't have control over the codebase to this degree, and the expectation from the company is more about business profit, more usage, etc., instead of building something that will not need to be rewritten.

In other words, the article misses the huge factor that companies don't care enough to allow FE engineering to be about building things properly, and instead make it something akin to a product owner with technical skills.

Re: The Frontend Treadmill

#307

Post by isleyaardvark »

Aurornis wrote: post #161
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…

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

Maybe now that’s a factor, but this has been a problem with FE development for many years, well before these influencers showed up.

Re: The Frontend Treadmill

#309

Post by kerkeslager »

PaulHoule wrote: post #100
kerkeslager wrote: post #23

Earlier quoted context omitted.

I've been writing React professionally for over a decade and React from 5 years ago is obsolete. Like, literally won't build with current tools. To their credit, I think the React code itself has maintained reverse compatibility pretty well (it's not React's fault), but the build systems I was using 5 years ago have all changed and broken reverse compatibility. EDIT: Forgot about component lifecycle methods... Even a…

Some of the problem with React and npm is that they are a victim of their own success. React lets you suck in 80 components from 15 different vendors and it works. NPM lets you suck in more dependencies than many other systems because it deals with diamond dependencies better than other systems [1] Because you can mix and match so many widget sets no wonder you will have trouble when those widget sets change. [1] pac…

The problem is more cultural than technical. JavaScript folks see the ready availability of dependencies as a feature rather than a risk, including the creation of a plethora of micro-dependencies (such as the left pad fiasco).

React itself is an exception which is well-developed because a competent developer team (Facebook's) depends on it. The vast majority of JS libraries are absolute garbage from idea to implementation to maintenance. Nobody should be depending on these libraries, and yet the vast majority of JS projects do depend on these libraries.

You can certainly run into similar problems in, for example, Python, if you decide to import all of pip with impunity, and there are certainly Python projects with this problem that I've worked on. But Python at least has a core group of commonly used libraries that keep sane dependency trees. You literally can't build modern JavaScript without using some bleeding edge nonsense that won't work in a few years.

Thankfully, as I've said before, you don't have to use the mainstream toolchains. Browsers and standards organizations have been much better about at least not breaking reverse compatibility.

Re: The Frontend Treadmill

#310

Post by nullpoint420 »

flufluflufluffy wrote: post #266
bloomingkales wrote: post #215

Earlier quoted context omitted.

Here's one: https://remix.run/ These grifters sell entire courses on the product, that's their game. So when you find an unmaintained Remix app at your company, well, the grifters got the ears of your junior devs :( And they just promote it and promote it: https://kentcdodds.com/blog/a-review-of-my-time-at-remix https://kentcdodds.com/blog/why-i-love-remix https://kentcdodds.com/courses Pure grift. But since most peo…

I find Remix really nice to work with, it’s a framework that embraces and utilizes web standards (what the article is arguing we should get back to doing more), and I’ve learned everything I know about it (and the majority of everything else I know about front end dev) for free. It’s not like you need to purchase courses to learn. At the same time, I don’t think there’s anything wrong with selling courses to teach pe…

But it _doesn't_ use web standards. It has it's own mental model and gotchas just like any other framework.
Post reply on HN