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

601–610 of 722 posts

Re: The Frontend Treadmill

#601

Post by BurnGpuBurn »

theknarf wrote: post #578

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

Funny story.

I started a new job in 2017 rewriting a rather large website with tons of functionality. The old one had to be replaced because it wasn't maintained and started to become a security issue.

I started doing JS and React/Redux for that job, and just as I was getting the hang of it React broke all my knowledge by coming up with "the modern way of writing React components", hooks. In my opinion there was absolutely nothing wrong with the old way of writing components. I never rewrote my now more than year old project, kept using the normal way of writing React components, which was still allowed. Two years later the depreciation messages started flashing by in the build process, and I was looking at a moutain of work having to refactor the complete front end.

Luckily I was able to move on to other things. But React always left the taste in my mouth of "don't, it auto-breaks after time".

I recently visited this old employer, and they have now hired a new coder to rebuild the old website, which is becoming a security issue.

Re: The Frontend Treadmill

#602

Post by sethammons »

wruza wrote: post #576
sethammons wrote: post #561

Earlier quoted context omitted.

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.

that's exactly what I mean. At the three python shops I've been at, teams reach across boundaries and add abstractions. This gets something out fast at first, but as the organization grows, if you are not diligent, the code organically grows and the ability to ship new things becomes increasingly tied to how other things are implemented.

What should take 1 team 1 sprint takes a dozen teams a dozen sprints. Code that shouldn't seemingly otherwise do so can get called in unexpected ways and take down your application. All this "you can do anything" ability leads to abstractions to solve niche issues that makes everything harder to reason about.

A great example: In django, a property on a model object might not be a property. This isn't limited to django, but that is where it bit me. So "customer_record.billing_type". Having loaded the customer_record, one might assume that you could access a property on it with little to no issue. Nope. Python lets you treat that property as a method, and now a hot loop in our code is making a network request to load load more data from a different databases. To prevent this requires mental load, knowing what properties are properties and which are not.

Because in Python, it could be anything, even a boat, and you know how much we've wanted one of those --Peter G.

Re: The Frontend Treadmill

#603

Post by owebmaster »

When I started coding, 20 years ago, the frontend was HTML+CSS+JS. Now, it is still HTML+CSS+JS. The most used backend was perl/Java/C/C++, which is not the case anymore.

So which one changed more, frontend or backend?

Re: The Frontend Treadmill

#604

Post by owebmaster »

adamtaylor_13 wrote: post #172

I have fallen in love with the simplicity of Rails recently. Sprinkle a bit of stimulus where you really need it. Hell slap a turbo here or there. And other than that? Pure HTML. It’s downright lovely. And it’ll still work fine 20 years from now.

> And it’ll still work fine 20 years from now.

bold claim. A Rails project of 20 years would not work fine today without a lot of work.

Re: The Frontend Treadmill

#605

Post by owebmaster »

adamtaylor_13 wrote: post #385
squidsoup wrote: post #354

Earlier quoted context omitted.

Sure, but then your company grows large enough to want its own design system, and you have multiple applications that need shared components. How do you implement that in rails?

Step 1: Resist the urge to overcomplicate. Step 2: Don't build multiple applications that need shared components. Step 3: Profit I slightly tease here, but really these are all leadership decisions that you can simply decide against. I would never implement those things because they're largely profit-less decisions. Having 2 apps that operate slightly differently is okay—even under the same brand.

your 3 steps can be summarized in just one?

Step 1 - don't grow

Re: The Frontend Treadmill

#606

Post by owebmaster »

hsuduebc2 wrote: post #559

It’s kind of wild that local storage is still the go-to in most places. Just a single big string, and the only way to handle complex data is by endlessly serializing and parsing one massive JSON object.

That's a technical problem, most frontend developers (or backend monkeypatching FE code) are not capable of using IndexedDB.

Re: The Frontend Treadmill

#607

Post by owebmaster »

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.

Besides knowing JavaScript well, there are so many stable web APIs that are not used often. IndexedDB, WebRTC, PWAs, WebComponents, service workers, web/shared workers, Broadcast Channel API, File System APIs, Cache API...

Re: The Frontend Treadmill

#608

Post by larodi »

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

Sorry, but people been maximizing value with ASCII-rendered tables of numbers at least since DB2 and Oracle came out. The UI has always been regarded as a key to success, but there are plenty of examples of ugly-as-fuck UI, which otherwise does okay for whatever means was created.

Add to that the fact that Perplexity-like search-RAG-services would very soon start munching not only search, but a plethora of APIs exposed by various services. And perhaps incur costs on the user for it, but the point is nobody cares about nobody else's UI that much. In fact people would love to have dashboards of data shown for their own needs in some open manner, and this is what we should expect to come, not a fancier version of SVG/canvas/React/WEBGL whatever.

last time UI was disruptively innovated was when reactive-functional-spreadsheets were introduced at the end of 90s and it stayed as an engineering concept more than actual implementation.

later on perhaps html/browsers could've disrupted something, and it did for a while, but very soon (only 15 years later) the soc.net.bros were already abusing all the good things in it and now we mostly have closed apps running on top of the open web infrastructure, which is basically the same as running closed apps on top of the open linux ecosystem.

Re: The Frontend Treadmill

#609

Post by heisenbit »

A big part of the treadmill is that frontends are seen as interchangeable low level investments steered by sales. Short term superficial requirement drive development often by an external team. Funding for sustaining them is scarce. So after a few years - the original team disbanded except maybe a small fraction and when the list of must have changes become too painful a new team is assembled and with it comes a need to differentiate itself from the legacy and assert control of architecture and purse.

Re: The Frontend Treadmill

#610

Post by nobleach »

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 get why you might feel that way. Ryan and Michael used to run a company based around React training. They created React Router which some people love to complain about. They've since moved over to working for Shopify. Shopify pays for their development on React Router/Remix. They do NOT sell training anymore.

Kent on the other hand, worked with them for a short time. He makes his living selling training. Filling in a gap (selling training) isn't really a grift is it? The dude's got a family and he's found something he can sell.

Post reply on HN