Live data from Hacker News

Do Not Follow JavaScript Trends

pragmaticpineapple.com

61–70 of 275 posts

Re: Do Not Follow JavaScript Trends

#61
post #22

Earlier quoted context omitted.

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

The code in it will still run and work but there are much better patterns and features now that help you write more succinct and less error-prone code. ES6 and ES7 are widely supported now and are much better languages IMO.

Thanks, that's kind of what I thought. I recently, finally, took it off of my book shelf and stuffed it into a box in the garage, but it's been in the back of my mind a few times as I've been going through other resources. It's good for the historical understanding but I couldn't see it being terribly relevant today.

Re: Do Not Follow JavaScript Trends

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

But do we get it? If we get it, why is frontend churn so prevalent? I don’t think we get it.

Is front end churn really so prevalent? I hear this opinion all the time, but React is 7 years old. I've been using it for around 5 years, I think. Redux is 5 years old. How old does the most popular web framework need to be before we consider it to be low churn?

[Edit: Also, anecdote: before JS, I was mostly a C# developer, and the churn there was at least as bad, maybe worse in my personal experience. Over 15 years of my career, I had to learn ASP, then ASP.NET, and in the Windows app world, we went from WinForms to XAML, then .NET Core came out, and things shifted again... See Rails' history for more examples of churn. It's not like every other platform is a paragon of stability. Clojure is a bulwark of stability compared to just about anything else, but it's hardly fair to hold the front-end community up against that gold standard...]

Re: Do Not Follow JavaScript Trends

#63

A good way to not be completely overwhelmed by all the new tooling and frameworks is to have a strong grasp of the fundamentals, here are three foundational resources: "You don't know JS": https://github.com/getify/You-Dont-Know-JS "How browsers work": https://www.html5rocks.com/en/tutorials/internals/howbrowser... "High performance browser networking": https://hpbn.co/

Agreed. I think a lot of folks suffer from not understanding how web 1.0 worked and really groking REST/HATEOAS (which has since been hijacked for JSON APIs, which is complete nonsense.) Sometimes I jokingly call htmx "web 1.1 tech", but increasingly I wonder if I'm really joking.

Maybe people ignore fancy ideas like HATEOAS because they don't actually help them make something useful for users. This particular fancy idea appears to exist mostly so people can make comments like yours.

If this wasn't true, as a user you would notice if the thing you were using didn't use HATEOAS, even though it should. The thing's functionality would be deficient in some manner that you could discern. I doubt that has ever happened.

Re: Do Not Follow JavaScript Trends

#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 testing library”. The library authors are complicit in this. Rather than showing the pros and cons of both, the trends are being pushed, leading people to falsely believe they must rewrite their whole code base in my experience.

The troubling part for me is often those creating these trends may be working on a very different type of app. When you’re writing something complicated, and the ecosystem is dominated by patterns (also preached by Kent) that work best in simpler apps like “only write integration tests” it can be frustrating.

If Kent thought enzyme promoted anti patterns he could have technically made a docs PR or just written a thin layer on top of enzyme. Now we have yet another divisive issue. Getting him early access to new react apis and officially recommending RTL in the react docs (while he sells his training videos) make it sit worse with me. It doesn’t feel like the trends are always based on the merits, it feels more like “not invented here” and “nepotism” driving some of these trends for sure.

Re: Do Not Follow JavaScript Trends

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

Kinda funny the author refuses to evaluate a five-year-old (?) standard (fetch), labeling it a trend/hype. And what are they holding onto? A third party library they “used before”; even cited the number of GitHub stars — i.e. aggregate trendiness — to justify the choice. Pretty sure at some point someone dismissed it as a trend and held onto their XHR, and they would have had a better point.

Re: Do Not Follow JavaScript Trends

#66
post #31

tl;dr: use TypeScript, but don't worry so much about hooks. --- I recently switched my JS + PureComponent mobile app to TypeScript and FC Hooks. I felt motivated to do so because: - You cannot use hooks in PureComponent render(). The two modalities do not play nice together. - Many of the libraries I use like react-spring and react-navigation have fully embraced hooks, sometimes without an HOC equivalent. So I felt f…

I was initially kind of worried about TS. It has kind of a high barrier to entry with linter settings, typescript-specific setting, solving how to compile your code easily, learning the new syntax, etc. etc. I literally spent like an hour reading up on it and learning it, and I realized I never want to go back to a plain old JS. TS feels way closer to Java than to JavaScript, with its own quirks and way of functionin…

> TS feels way closer to Java than to JavaScript

You and I clearly have different understandings of Java, JS, and/or TS. Typescript's structural typing feels like the opposite end of the spectrum from Java's nominal types.

Re: Do Not Follow JavaScript Trends

#68
The user does care. At a previous company we started migrating from angular to vue. Vue was so fast that those parts would be completely rendered and the rest would be white. It was also snappy.

Of course, one has to be mindful about the transition. You cannot stop business, but you can take a little extra time whenever there's need to modify a section to improve quality (both code and ui). Actually that's why we chose vue, it allowed to a progressive migration out of angular.

BTW, someone had the "great" idea of not using a framework for an internal admin portal. It turned immediately into a huge ball of mud.

Re: Do Not Follow JavaScript Trends

#69
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.

My reasoning is pretty simple. For a new learner, unless you have a compelling counter example needing classes, you should use hooks. That’s what you should start off learning and that should be your go-to.

But if you click away from this comment, right now, go to Google, and search for tutorials, despite this “best practice” advice, you’ll see an unholy mess of tutorials citing classes, with a few using hooks as though it’s some kind of new fangled, “out there” tech. I’m talking in the top 10 search results on Google’s front page. In 2020, long after the React team has introduced and explained them.

Look, it’s simple. Aside from their other advantages, hooks make it easier to learn React, with less boilerplate. As a result, it would be better if beginner tutorials were updated to use them. Most have not been.

But I see this complaint regularly, where hooks are trotted out as some kind of example of silly React maximalism. If you learned React then hooks are only going to take up like 2% of the total time budget you’ve already dedicated to learning the framework. It’s not hard, and it’s nothing like learning, say, Haskell. Using hooks to make cheap shots against overcomplicated JS frameworks is unfair, when they’re not overcomplicated and have a perfectly valid reason to exist.

Re: Do Not Follow JavaScript Trends

#70

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…

Analogy: Like looking at stock prices. As javascript developers, we see all the tiny changes every day and it can feel overwhelming. However, looking at with a long-term view, there are only a few major spikes and it seems to be nicely growing.
Post reply on HN