Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Do Not Follow JavaScript Trends

pragmaticpineapple.com

Post reply on HN
Print view View original

81–90 of 275 posts

Re: Do Not Follow JavaScript Trends

#81

Post by hn_check »

protonimitate wrote: post #56
duxup wrote: post #9

I'm a little lost on the examples. There are reasons to use fetch and hooks, and the article seems to relegate them to being unnecessary 'trends' without doing what it suggests, actually evaluating what value they might have... In React you can use hooks with a class heavy application and still be just fine / get the benefits of hooks in a given component(s). If you want to use fetch, that also is hardly an ordeal to…

Yeah, I'm becoming increasingly frustrated by the flood of "anti-hype-driven-development" blog posts being praised. The entire article could be summed up with: > Is it solving your problem, and what is the cost? And it cuts both ways. Change for the sake of change is bad. But so is stagnation for the sake of stagnation. Picking the best tool for the job and continuous improvement are the closest thing to universal ad…

In the JavaScript/web framework space, it is absolutely remarkable how much running to stand still occurs. How people making absolutely trivial apps have megabytes of frameworks, having injected many magnitudes extra complexity, for illusions. It's bizarre.

It's like web developers have some major inferiority complex so there's this desperate need to make responding to a button and changing an input into some monstrosity of hilarious over-engineering, the result being some colossal piece of shit.

There have been incredible advances in software engineering in general, but the web space is really a counter-example -- I really don't feel there has been beneficial movement in a decade or more. Which is why frameworks and approaches are all so temporal -- the lack of legitimacy makes it so easy to unseat for the next silver bullet for hilariously simple apps.

Re: Do Not Follow JavaScript Trends

#82

Post by [deleted] »

dahfizz wrote: post #15
phailhaus wrote: post #12

Earlier quoted context omitted.

> What is possible today that was very hard to do 10 years ago in web dev land? Declaratively writing components and reusing behavior (e.g., hooks) across components/applications was basically impossible with the tools of 10 years ago. The benefit to the user is more stable interfaces and a faster release rate.

> benefit to the user is more stable interfaces Doubt. Websites are constantly redesigning their interfaces so that they can use the latest trendy technology.

[deleted]

Re: Do Not Follow JavaScript Trends

#83

Post by mcescalante »

mark_and_sweep wrote: post #40
Tade0 wrote: post #14

I feel like these problems are endemic to React and the surrounding ecosystem. Since its introduction in late 2016 Angular 2+ has had no major changes on the scale of hooks and is unlikely to introduce them, because its target audience - large companies making large-scale applications is fairly conservative. Vue I think had one measurably large syntax shift around v2.5(or 2.6) and will have another one with 3.0, but…

> Since its introduction in late 2016 Angular 2+ has had no major changes As someone who has used Angular 2 since beta, I can tell you, it's been a bumpy ride nonetheless. > its target audience - large companies making large-scale applications - is fairly conservative React was built for Facebook, which is a large company building a large-scale application. > All this won't matter once the next gen compiler-framework…

> As someone who has used Angular 2 since beta, I can tell you, it's been a bumpy ride nonetheless.

I can second this - I've been working on a variety of Angular apps in an enterprise environment. It's worked fine and the "batteries included" has worked for my org, but it has definitely been a bumpy ride to get from beta to 9 with plenty of changes along the way.

> And here I am using HTML and CSS with tiny sprinkles of JS for most websites, and it's working just fine, and has been for many years.

This has been my favorite setup at work - pick "boring" tech like Django/Flask or Spring Boot and then sprinkle in some Javascript for highly interactive forms/pieces (React or Vue if needed).

Re: Do Not Follow JavaScript Trends

#84

Post by User23 »

recursivedoubts wrote: post #7

Javascript has always gone through hype cycles. Interestingly, it appears to be somewhat correlated with market manias and peaks near the tops of markets. Generally, following industry trends appears to be good for individual careers but bad for code bases (on average, but with occasional big payoffs.)

Since I own my career but signed away all rights to the code I write as a condition of employment I'm OK with this trade-off.

Re: Do Not Follow JavaScript Trends

#85

Post by robjan »

k__ wrote: post #58
itronitron wrote: post #21

Earlier quoted context omitted.

Serious question, why do they need to know anything about creating prototypes?

The argumentation went like: We did design projects for companies and showed them our ideas as mock images and they didn't like them. We then implemented the exact same designs as prototypical apps, they clicked around in it and loved it.

You can mock user interactions in Sketch and Figma.

Re: Do Not Follow JavaScript Trends

#86

Post by duxup »

julianeon wrote: post #69
duxup wrote: post #9

I'm a little lost on the examples. There are reasons to use fetch and hooks, and the article seems to relegate them to being unnecessary 'trends' without doing what it suggests, actually evaluating what value they might have... In React you can use hooks with a class heavy application and still be just fine / get the benefits of hooks in a given component(s). If you want to use fetch, that also is hardly an ordeal to…

I’m personally becoming frustrated by the “we draw the line at React hooks” idea - which I feel like I’m seeing repeated. Like that’s the point at which learning new concepts crosses over from useful exercise to useless extravagance. So let me say something which is true, but totally against the spirit of this article: there should be 10x as many (!) tutorials about how to implement everything in React using hooks. M…

Yeah hooks have such a low barrier to entry as far as ... just make a new component with hooks. There is less code, it's easy to do, anyone who has seen a class component doesn't need much of an introduction to understand it.

I've got class heavy applications that will stay class heavy, but almost all new components are hooks and they're quick to write, evaluate what is going on, and work with.

Re: Do Not Follow JavaScript Trends

#87

Post by k__ »

robjan wrote: post #85
k__ wrote: post #58

Earlier quoted context omitted.

The argumentation went like: We did design projects for companies and showed them our ideas as mock images and they didn't like them. We then implemented the exact same designs as prototypical apps, they clicked around in it and loved it.

You can mock user interactions in Sketch and Figma.

I don't use these apps.

It were design teachers that hired me, so I guess they knew and still wanted their students to learn a bit programming.

Re: Do Not Follow JavaScript Trends

#88

Post by onion2k »

mxschumacher wrote: post #3

From a developer perspective, changes in frontend web development have been pretty dramatic: CSS Grid / Flexbox, React, WASM, extensions to the web API, lots of new JS features, countless frameworks, plugins and build tools more homogeneity between browsers. There is always lots of change and excitement. I wonder how much of that "innovation" really makes a difference to users. As a programmer, I get a bit cynical ab…

I want to break this list of things down a bit;

CSS Grid / Flexbox - Flexbox was defined in 2009, and was added to browsers about 10 years ago and iterated since. It was literally in the first public version of Chrome. This is not some new tech that's blindsided everyone. Grid is a couple of years old.

React - First released 7 years ago and iterated since. Reasonably mainstream for 5 years. That's not a very dramatic change.

WASM - Around for a few years now in browsers but tooling for different languages is still patchy. Entirely unnecessary for 99.9% of web development. Most people are still in the "use it because it's cool" phase rather than "use it because it's actually useful".

extensions to the web API - Various, obviously. Can't really argue this point.

lots of new JS features - Various, but not actually very fast moving with new features. Most things are made available earlier through transpilers, so you can use a feature without it being in mainstream JS engines if you want to. Can't really blame the web if you make that choice though.

countless frameworks - You don't need to learn them all. Pick any number to use between zero and all of them depending on how much time you want to spend learning frameworks. Again, this is a choice, and if you're finding it overwhelming it's because you picked the wrong number of frameworks to learn.

plugins and build tools - Same answer again. Pick something and learn it. Update your skills every few years if you think your tooling is holding you back.

more homogeneity between browsers - This reduces complexity. To complain about that in a list of things to taking up your time is weird.

The web isn't that fast moving. I completely agree with your point about focusing on things that benefit the user though. I would argue that frameworks and build tools that enable me to iterate features faster do that though.

Re: Do Not Follow JavaScript Trends

#89

Post by omniscient_oce »

joshribakoff wrote: post #64

I find it interesting the blog post mentioned Kent Dodds article recommending everyone rewrite fetch. I just argued adamantly against Redux docs about writing tests being switched off of Enzyme to his library because it’s “more trendy”. https://github.com/reduxjs/redux/pull/3708 Unfortunately, the community overruled me and the docs no longer show how to test Redux apps with enzyme. It only shows Kent’s “react testin…

react-testing-library and Tailwind are two tools that I use that I feel the userbase are a bit cult-like.

I don't know if it's "not invented here" syndrome so much as people use tools based on people, not always just merit.

Kent and Adam had similar self-promotion engines running with long-form free video tutorials and strong social media presence, blog posts online, etc. Perhaps this style of promotion more of a tool more than anything is effective at changing the status-quo tools?

(Not saying they're necessarily better or worse, just my observation of why they may have become popular)

Re: Do Not Follow JavaScript Trends

#90

Post by piyh »

scruple wrote: post #22
no_wizard wrote: post #16

Earlier quoted context omitted.

I also want to add the great Eloquent JavaScript[0] to this list. While its targeted at learning programming as a whole, its still a wonderful resource, even for seasoned programmers, to learn some ins and outs of the language if you haven't had a lot of experience with it. I also want to give mention to JavaScript: The Good Parts by Douglas Crockford[1], and his new book, How JavaScript Workers[2] [0]: https://eloqu…

> JavaScript: The Good Parts by Douglas Crockford I've been wondering lately, as I'm moving (back) into a JavaScript-heavy stack (it's been... 4-5 years for me), is this book still relevant in the face of 12 years of JavaScript language development?

As a noobie, Eloquent Javascript was much better for me than The Good Parts. The Good Parts was a book of how not to program, followed by the right way of doing it. Eloquent was a guided path to understanding the language without being shown all the dead ends.

Knowing the dead ends and the history behind them is nice, but I spent a lot of brain power on the dead ends that Eloquent put towards better use.

We're also talking a small book vs a tome of knowledge, but the philosophy is different regardless of size.

Post reply on HN