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

51–60 of 275 posts

Re: Do Not Follow JavaScript Trends

#51

Post by ratww »

phailhaus wrote: post #12
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…

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

In Javascript, maybe, but frameworks like WebForms already had 1st-party components (called "user controls") back in the early 2000s. Granted, it was server-side only.

Hooks are a tough one (they're very specific to reactive frameworks), but we did have other kinds of abstractions that provided similar benefits.

Re: Do Not Follow JavaScript Trends

#52

Post by jakelazaroff »

tobyhinloopen wrote: post #20
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.

I totally disagree. Reusable components were already there using jquery plugins. Everyone used them and they were easy to use and easy to install. They were deployed as a single file, with optional CSS. Try writing a reusable component now. You have to target all major frameworks and tooling.

Components as jQuery plugins aren’t encapsulated or easily composable. What do you do if two plugins used the same namespace or class names? How would you put one component inside another?

Re: Do Not Follow JavaScript Trends

#54

Post by heipei »

wereHamster wrote: post #29

Let me make the argument against axios. Even if you are happy, your users may not. Axios (btw still on version 0.x despite being one of the older javascript packages, means it can introduce breaking changes without any warning, think about that) adds 4.4kB (minified+gzipped) to your bundle. Do that a few times and you have hundreds of kB of additional code your users don't need to download (and execute!). If all you…

My argument for using axios is developer ergonomics. There are a few libraries that I use both in the frontend and the backend, for which I gladly accept the increased bundle size: axios, lodash, moment, Q. My users get the benefit in me being able to ship features faster because I don't have to constantly keep up with which feature ships in which browser version etc. I also found the fetch API horrendous to use. It's a tradeoff I'm willing to make.

Re: Do Not Follow JavaScript Trends

#55

Post by memexy »

ChrisMarshallNY wrote: post #42

Not just JS. JS is an enormous ecosystem, so it shows this issue, but pretty much all tech (and other industries, as well), have the same problems. We can have problems when folks start suddenly painting "The New Thing™" over classic designs and architectures. In my experience, that's even worse than rewriting everything. Also, it can become a requirement for hiring, because some manager, or their "top tech," have su…

I once worked with a group of people that were afraid of makefiles. I doubt it was your age. People are always afraid of things that are unfamiliar. This applies to snakes and spiders just as much as it applies to programming languages and associated technologies.

Re: Do Not Follow JavaScript Trends

#56

Post by protonimitate »

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 advise in front-end land.

The "everything new is bad" rhetoric is getting exhausting.

Re: Do Not Follow JavaScript Trends

#57

Post by benrbray »

no_wizard wrote: post #16
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/

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…

I would like to take this opportunity to point out that the author of "Eloquent JavaScript", Marijn Haverbeke, also created both CodeMirror and ProseMirror [1], which are both extremely well-regarded open source code/text editing tools. I can especially recommend ProseMirror after spending a lot of time with it recently. It's an actually sane wrapper around contenteditable.

[1] https://prosemirror.net/

Re: Do Not Follow JavaScript Trends

#58

Post by k__ »

itronitron wrote: post #21
k__ wrote: post #13

I'm teaching frontend development to designers right now and after almost a semester, I have the feeling I have to cut out much more concepts. There are just too many ways to do things to teach a beginner in one semester and they just should be able to create basic prototypes anyway.

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.

Re: Do Not Follow JavaScript Trends

#59

Post by arvinsim »

BossingAround wrote: post #46
jchook wrote: 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…

The number one pain point for me is that sometimes time is wasted tracking TS error or bugs than actually solving my problem.

Re: Do Not Follow JavaScript Trends

#60

Post by nsonha »

BossingAround wrote: post #46
jchook wrote: 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…

To me I sometimes get too obsesded with types and try to wrire clever ergonomic type inference. Usally I stop when I realize the types are double loc comparing to the actual implementation or what I was trying to do was impossible. It can be a drain on productivity if you're like me.
Post reply on HN