Live data from Hacker News

The front end community wants to wash its hands of the decade we lost

twitter.com

21–30 of 87 posts

Re: The front end community wants to wash its hands of the decade we lost

#21
post #18

Earlier quoted context omitted.

I'm in the same boat, I was expecting some punchline .. it's just moaning without anything concrete

I couldn’t even get through it. I sort of hate Twitter threads. Lost are the days of making your point in 140 characters or less.

Haha I created an account just to agree. There’s no content to this twitter thread. I think he’s anti mainstream? That’s his signal?

Re: The front end community wants to wash its hands of the decade we lost

#22

This is just good old cargo cult JS Framework Fatigue but then in a fancy “thought leader” writing style, yes? Am I missing some fundamental new insight?

The point I got from the mini-rant was that we have been going down this path of ever-increasing complexity (and ever-increasing client burdon) with this inherent belief that it would result in something better.

Better could be "user experience", or "client behavior control/consistency", or ? something. But have we really done side by side comparisons and gathered real evidence?

My instinct is that 80% of websites can be HTML and comfortably meet user needs. Another 15% can sprinkle in a little JS to make some targeted improvements. And finally, maybe 5% really do need full JS frontends.

Our problem in general is that we like shiny new things, clever things, and things which we think will make our developer lives better. But it seems we end up overdoing it, approaching each new thing as if it were a silver bullet.

The Phoenix Framework (LiveView) crowd, and later the Rails (Hotwire) crowd show that you don't need a complex SPA to get user-positive experiences. I have a strong opinion on which of the two does this better and more simply, but that's a separate discussion.

Re: The front end community wants to wash its hands of the decade we lost

#23
post #12

I feel the author misjudges the people making these decisions because for them in their own situation, the choice of large frameworks isn't the right one. But many smart people are in different situations in which the best decision is to use a framework. If I'm Amazon or Google and each ms of time to page load (p99 and average) is measurably worth a 6+ figure sum of money per year, then yes, cutting out the framework…

This makes three shaky if not outright wrong presumptions:

1. The only reason to cutting out the framework is speed.

There are many reasons to forego a framework. Coupling, maintenance[1], dependencies or simply "keeping it simple" are some of the parameters to take into consideration when choosing for or against a (certain) framework.

More practically: I'm writing a simple job search engine[2]. Plain, vanilla JS, some \ tags, and a library to communicate with the search backend. I dont' yet need anything react-redux-saga-event-based yet. This approach is reaching its limit, but I now have the proper information to make a better choice. I did not have that when I started, so I would've certainly picked the wrong framework and painted myself in a corner there.

2. Without a framework we cannot iterate quickly

As I point out in my blog[1] article, this is has often (but not always) be proven to be exactly opposite. Obviously depending on context and use-case. But there are many situations in which a framework is holding you back. In which it is actually slowing the project down, rather than speeding it up. Frameworks, famously, allow a rapid start, and therefore are great for PoCs, Demos, prototypes, MVPs or even "run-off-the-mill-agency-produce". But over time (think years, decades) often get in the way, hold the project back. Just think of the wasted eons of all engineers "rewriting project P from scratch"; often because it turns out that the current version/market/tech/use requires things that no longer fit the boundaries the framework imposed. Bouddaries welcomed or disregarded when the framework was chosen a decade (or just years) ago.

3. Smaller teams need a framework

See above. But also: what a small team needs is reusable code. Libraries. Not Frameworks per-sé, but libraries. Preferably implemented behind decoupled, isolated layers; away from business-logic. Or, more modern, SAAS, PAAS, IAAS. reusable stuff, preferably implemented behind isolated layers.

[1] https://news.ycombinator.com/item?id=33185010 [2] https://search.flockingbird.social/

Re: The front end community wants to wash its hands of the decade we lost

#24

Ah, yes. Everyone’s favorite whipping boy: the front end developers. I don’t think the last decade was a mistake. React (and Preact and similar) are my favorite ways to build out UIs. I prefer it to every other thing I’ve tried— and I’ve tried just about every other thing, including building native UIs for a decade. It’s not perfect. I think we’ll find a better approach eventually, which is why I’m fine with the chur…

> React (and Preact and similar) are my favorite ways to build out UIs

Sadly, they're not what your users want.

Re: The front end community wants to wash its hands of the decade we lost

#25

Ah, yes. Everyone’s favorite whipping boy: the front end developers. I don’t think the last decade was a mistake. React (and Preact and similar) are my favorite ways to build out UIs. I prefer it to every other thing I’ve tried— and I’ve tried just about every other thing, including building native UIs for a decade. It’s not perfect. I think we’ll find a better approach eventually, which is why I’m fine with the chur…

I hate my spouse's lousy cooking; the slow, clunky way their hips move when they walk; but most of all, their cringe poetry. But until I find someone better or at least less embarrassing to be seen with in public, I'm sticking with 'em. OK, so what about Vue.js? Or is it dead to you already?

I think you are missing the point.

React/Vue/Angular/Whatever are different flavours of the "framework oriented front end development" thing. Yes there differences in both technices and degree you are forced to use only that framework but the principles are essentially the same.

Re: The front end community wants to wash its hands of the decade we lost

#26
post #4

This seems to refer to some new consensus that everyone now agrees to, but I am not sure what they are referencing. Does anyone know?

The consensus is that "good frontends need to be all done in JS, whether React or Vue or Angular or ...".

It's like the blockchain craze that thankfully has passed. A few years ago, any company worth anything had some kind of blockchain project, because "everyone knew" that blockchain was some magic thing that would make your business (and your product) better. Certainly some levels of upper management believed this, and they saw their peers embracing it.

It's the same, but older, for JS-heavy frontends.

The point is that we should carefully re-evaluate how we got here and if we indeed have reaped rewards great enough to compensate for the immense additional complexity.

Re: The front end community wants to wash its hands of the decade we lost

#27
post #18

Earlier quoted context omitted.

I'm in the same boat, I was expecting some punchline .. it's just moaning without anything concrete

I couldn’t even get through it. I sort of hate Twitter threads. Lost are the days of making your point in 140 characters or less.

I've never seen an interesting point that could be made in 140 characters or less. That limit works for jokes, headlines, and almost nothing else.

Single-tweet "wisdom" always turns out to be something so broad/unqualified that it's uninteresting or untrue. VC Twitter is basically a deluge of that kind of faux-profound nonsense.

Re: The front end community wants to wash its hands of the decade we lost

#28
The problem is misaligned incentives.

Sure, for my personal projects I am all about KISS but at work, if someone insists we try out this new framework and build a super complicated SPA, why not?

People make fun of resume-driven development but besides the money which obviously is the main benefit of having a job, experience is the other big thing that a job can offer. It is in my best interest that we use the most complex solution. I like the challenge.

Lets be honest, most fronted jobs could be rationalized away and the products would actually be better. It depends on your exact business but in many areas there is not point in keeping your UI "fresh". I have seen lots of redesigns actually HURT sales. Once you have found a design that works for you target customers, just keep riding the good thing.

So yeah, things are insane but as a developer it is neither in my power nor in my interest to change anything.

Re: The front end community wants to wash its hands of the decade we lost

#29
post #25

Earlier quoted context omitted.

I hate my spouse's lousy cooking; the slow, clunky way their hips move when they walk; but most of all, their cringe poetry. But until I find someone better or at least less embarrassing to be seen with in public, I'm sticking with 'em. OK, so what about Vue.js? Or is it dead to you already?

I think you are missing the point. React/Vue/Angular/Whatever are different flavours of the "framework oriented front end development" thing. Yes there differences in both technices and degree you are forced to use only that framework but the principles are essentially the same.

So what other kind of thing do you suggest (and which currently has some traction)?

Re: The front end community wants to wash its hands of the decade we lost

#30

'toxic positivity' that's a new one

Yeah, that's the part that really kills me about JavaScript. I can deal with the language, npm, some curious conventions in the community, every "npm install" telling me I have 100+ security vulnerabilities. It's the whole "THIS IS THE MOST AWESOME THING OF AWESOMENESS SINCE THE INVENTION OF AWESOMENESS!!!!" that kills me, which is really just my snarky way of saying that I found there's generally some serious lack o…

Toxic positivity goes a step further. It's not just the gung ho "everything is awesome". There's also pushback against critique. In some communities, you can't say, "this project has aspects that are not good" without getting met with "be quiet, the devs are trying really hard".

I'm sorry, but certain things shouldn't involve participation trophies. Building bird houses with your kids in the backyard, yes. Building anything at least as complex as a toolshed for other people, no. At a certain point (i.e. when our work can have consequences for others), we have to take responsibility for our work, and expect responsibility from others.

Post reply on HN