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

91–100 of 275 posts

Re: Do Not Follow JavaScript Trends

#91

Post by Ataraxy »

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 would also argue in direct contrast to the author that it makes a difference in terms of keeping interest. The new thing to learn in a dynamic ever changing landscape is also a way of staving off monotony.

I legitimately don't care about React hooks though one way or another and it's a bizarre thing to draw a line at.

Re: Do Not Follow JavaScript Trends

#92

Post by andrewl-hn »

I vividly remember 2016. I was doing backend programming at the time, but no one I knew were using Angular.js at that time for new codebases.

React emerged in 2013, by 2014 the hype was at full swing, and by 2015 React "won" the framework battle.

It's been 5+ years since then, and React JavaScript world was remarkably stable. Fashion changes were largely superficial: React.createClass vs ES classes, Heavy use of Decorators vs not using them, and now Hooks. These were mostly cosmetic choices, and if your team picked the wrong side they could migrate over relatively painlessly or straight up ignore the issues for years.

On the other side of spectrum we have Ember that maintained backward compatibility and ease of upgrades since ~2013, Angular 2+ is doing the same for many years, too.

The whole "JavaScript fatigue" meme has to go.

Re: Do Not Follow JavaScript Trends

#93

Post by diffrinse »

The problem to me isn't so much hype trains for this or that framework but that, as a Front-Ender myself, many Front-End Devs don't know how to do anything without a framework; the person I report to, the Front-End Manager, had been mucking about with jQuery for 15 years straight and didn't know about CSS animations.

I was able to work alongside a very saavy consultant for a year when I started out who I feel pointed me in the right direction wrt coding 'from the problem itself', if you will, but they'd have me do interviews and I'd be astounded at what applicants didn't know or grasp who'd been doin this front-end thing much longer than I.

If there were better solution design pedagogy instead of React's original marketing of "We know better about efficient DOM updates than you" I think you'd see substantially less reliance on these types of things, and probably a lot less unmaintainable code disguised as maintainable because it uses "a framework".

Re: Do Not Follow JavaScript Trends

#94

Post by sushshshsh »

thanatropism wrote: post #23
recursivedoubts wrote: post #10

Earlier quoted context omitted.

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.

In 1996-1998 as a teen I "made some websites" for local businesses. The one I made for my parents even had a search function (in PHP) in a CSV with their products (which were like 100). The CSV was generated by taking whatever Lotus Approach (their desktop DB) generated and transforming it with some custom Haskell code (I was a teen, what did I know). They clicked an icon to pull the data and another to run a FTP bat…

.componentInQuestion { whateverBackgroundTagIsCorrectInCss: #hexvalueForColor }, no?

Re: Do Not Follow JavaScript Trends

#95

Post by fidelramos »

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?

Unless the book has had an updated edition it's missing all the ES6 good stuff. It was good to avoid the pitfalls of JavaScript in the past, but nowadays you should be using ES6, strict mode and, if that strikes your fancy, TypeScript.

Re: Do Not Follow JavaScript Trends

#96

Post by strangescript »

andrewl-hn wrote: post #92

I vividly remember 2016. I was doing backend programming at the time, but no one I knew were using Angular.js at that time for new codebases. React emerged in 2013, by 2014 the hype was at full swing, and by 2015 React "won" the framework battle. It's been 5+ years since then, and React JavaScript world was remarkably stable. Fashion changes were largely superficial: React.createClass vs ES classes, Heavy use of Deco…

100%. Normally these articles are thinly veiled attacks on something that has changed in the author's coding ecosystem that has angered them. When I saw hooks in the first few paragraphs I assumed it was going to be a "hooks are bad, mkay" article. It isn't, but still some what vague on actionable points or ideas.

Ultimately no one likes rewriting code and is typically under-estimated since developers mentally trivialize previous work rather than a greenfield affair.

Re: Do Not Follow JavaScript Trends

#97

Post by squeaky-clean »

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?

I personally never really liked that book even when it was new. It's good if you wanna get up and running with JS fast while coming from another language, and are forced to use JS in places but it's not the main language of your project.

But it doesn't really give a strong foundation on understanding the language. It's more like "I know mainstream C-inspired languages, and JS often burns me with its weird quirks like how the this keyword works, I just want to avoid getting burned". But it doesn't really embrace JS itself, just sort of acknowledges that you will be forced to use it in the web so you may as well at least learn the "good" parts.

It's still decent at that purpose, but for really strong competency in JS I can also vouch for the Eloquent JS book and the You Don't Know JS series (I've only read the first edition, a new edition is partially complete and available online).

Re: Do Not Follow JavaScript Trends

#98

Post by nailer »

oefrha wrote: post #65
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…

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.

> Kinda funny the author refuses to evaluate a five-year-old (?) standard (fetch), labeling it a trend/hype. And what are they holding onto?

Fetch is a very poor standard if you compare it to high-level HTTP clients that have been around since 2010-ish. However it's author states that it wasn't intended as a general purpose HTTP library but rather a low level tool that-level tools can make use of.

So yes: you probably don't want to use fetch directly, making Headers objects using obscure methods, manually encoding query strings, and telling your HTTP client that you'd like to treat application/json as JSON and decode it. Use a library.

Re: Do Not Follow JavaScript Trends

#99

Post by JMTQp8lwXL »

mxschumacher wrote: post #5

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/

Somewhat agree. Fundamentals help, but understanding them won't immediately clarify every configuration item in a Webpack configuration.

Re: Do Not Follow JavaScript Trends

#100

Post by leanstartupnoob »

recursivedoubts wrote: post #10
mxschumacher wrote: post #5

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.

> not understanding how web 1.0 worked and really groking REST/HATEOAS (which has since been hijacked for JSON APIs, which is complete nonsense.)

Anyone who really grokked REST would never say it's nonsense to use with a JSON API.

Post reply on HN