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

261–270 of 722 posts

Re: The Frontend Treadmill

#261

Post by skeeterbug »

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…

I recently had the opposite experience. App was built in older version of React/MUI/CRA/tsc (project started in 2020). I upgraded everything to latest, removed CRA for vite, and it just worked for the most part (vite has some docs for upgrading from CRA). MUI had a few things deprecated, but it didn't break. Removed the yarn lock and switched everything over to vanilla npm now that it has package locks. Took < 1 hour.

Re: The Frontend Treadmill

#262

Post by bloomingkales »

pookha wrote: post #228
mablopoule wrote: post #146

Earlier quoted context omitted.

I don't think it's a Javascript problem in the sense that it's due to intrinsics properties of Front-end developpement, or of NPM, but I do agree that's in a cultural problem in the Javascript ecosystem, especially around React. My theory is that there was a perfect storm around 2015 where everyone and their dog was encouraged to learn to code, especially by going through a coding bootcamp where they were mainly taug…

LOL 2015 was a banner year for the trendy web-dev influencers...I can remember junior developers tripping over themselves trying to implement "flux" to handle some form input. Needlessly complex bullshit libraries got forced down everyone's throat because AngularJS was passe and React was "very mindful, very demure". Eventually flux became "redux", which I gather was a "state management" framework that ripped off a p…

We need a Behind the Javascript VH1 show.

Re: The Frontend Treadmill

#263

Post by ForTheKidz »

Kerrick wrote: post #115
ForTheKidz wrote: post #19

Why does FE development have such churn? Desktop toolkits from 30 years ago work just as performantly today; what is so difficult about the browser that demands constant framework updates?

Hmm... React, Backbone, jQuery. SwiftUI, AppKit, Cocoa, Carbon, Toolbox. WinUI 3, UWP, WinRT XAML, WPF, WinForms, Win32 GDI. --- Of course this is misleading, because React has had so much internal churn. But desktop toolkits also have churn.

Yes, of course. In good faith, I'm not trying to accuse specific WWW frameworks of being less-backwards-compatible—react has actually done a pretty damn good job of guiding people along upgrades. But culture-wise there's a massive difference in discourse, and native apps still have the best quality. Spotify's app is horrifically bad; slack and notion could be worse, but these are hardly examples of excellence. Apps that do perform well seemingly need to hook directly into native widgets to compete (see: tiktok).

(And sure you could view AppKit/Cocoa/SwiftUI as distinct frameworks, but ultimately they're all just different interfaces to the same event loop and there's typically a clear indication which one you should be using in which context. The transition from Carbon to Cocoa took more than a decade to complete!!! Most of my Cocoa code from the era can be gotten to compile with modern macosx in under an hour, and most of the performance lessons from then apply directly to AppKit. SwiftUI can and should be used as a wrapper around these views if possible.)

Re: The Frontend Treadmill

#264

Post by jchw »

gavinray wrote: post #253
mlboss wrote: post #223

Earlier quoted context omitted.

Are you using the same version of React that you started 10 years ago? More importantly can you use the React version that was 10 years ago ? Can you even build a 10 year project ?

In React 10 years ago, you included a tag in your HTML page and added interactivity via "React.createClass()" function calls.

To be fair...

Webpack existed 10 years ago, and that was after Browserify had already existed for a bit, too. The era of bundling was already in full swing in 2015, and React gained support for ES Classes, too.

React wasn't really terribly usable without bundling. Prior to bundling, there were multiple competing adhoc module systems, but obviously this wasn't fantastic for a variety of reasons. AngularJS 1.0 was great in part because the dependency injection system kind of took care of a lot of trouble; you could have a workflow in Gulp/Grunt concatting your JS together, and the order didn't really matter a ton since dependency injection would largely handle it.

React moved relatively quickly in the first few years, but 10 years ago was already not the very beginning of React. It was starting to mature by that point.

Re: The Frontend Treadmill

#265

Post by namaria »

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.

I think you mean exacerbated

Re: The Frontend Treadmill

#266

Post by flufluflufluffy »

bloomingkales wrote: post #215
ewzimm wrote: post #171

Earlier quoted context omitted.

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…

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 people about a framework. But the idea that the entire thing was created just to sell courses about it is not true.

But I do agree that there’s just way too much fast moving, breaking changes on front end in general, frameworks released every other week, etc…

Re: The Frontend Treadmill

#267

Post by evantbyrne »

bloomingkales wrote: post #250
evantbyrne wrote: post #243

Earlier quoted context omitted.

I suspect the cultural issues with JS primarily boil down to the fact that every org needs JS, which in turn results in 1) a glut of junior/mid devs and 2) it naturally being ground zero for hype cycles. At this point I honestly wonder if most orgs should even hire for JS skills, or if they would be better served by hiring backend engineers and training them to write progressively enhanced UIs.

The thing is brilliant UI engineers will stun you with incredible UI. It's almost like not investing in AI, you will get blind sided by products that just look and feel better. Your backend engineers are never going to cut it. This is true for backend engineers too, if you try half ass it with "full stack" devs, brilliant backend devs will stun you with things and your products will be inferior. For example, we all g…

backend and frontend engineers aren't as distinct from each other as they are from ML or something like embedded development. It is very normal to be able to build a web interface end-to-end, and frankly something I expect of every competent developer in that space. Someone who is a high-performing frontend engineer should also be able to perform at a high level in backend, and vice-versa. I'm talking about the industry as a whole though, and specifically that I wouldn't trust the average "frontend developer" to be making wise engineering decisions. Saying this coming from a background of working with designers on webby award winning projects and having a high degree of respect for the platform.

Re: The Frontend Treadmill

#268

Post by metalforever »

mystifyingpoi wrote: post #182
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 a lot of people are yearning for the "good old days", where you'd install Apache, drop some .php files into /var/www and start hacking around with only static HTML and maybe a sprinkle of progressive-enhancement JS here and there. I think it's totally okay way to build a dynamic webpage . But web application ? Not so sure.

Everyone thinks they have a web application but a lot of the React I get asked to build could have easily just been a dynamic webpage (it is usually a dashboard). I think there is an over-emphasis on what constitutes a "web app".

Re: The Frontend Treadmill

#269

Post by koakuma-chan »

bob1029 wrote: post #240
koakuma-chan wrote: post #211

Earlier quoted context omitted.

> I think the end game is doing SSR of web content inside the RDBMS OR just embed the RDBMS into your application!

SQLite is certainly a very good option. You could bind a handful of UDFs and turn it into a poor man's Oracle stack. https://www.sqlite.org/appfunc.html

It's also very easy to do in Rust.

https://github.com/rusqlite/rusqlite/blob/master/examples/lo...

Re: The Frontend Treadmill

#270

Post by metalforever »

AlexMoffat wrote: post #42

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.
Post reply on HN