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

31–40 of 275 posts

Re: Do Not Follow JavaScript Trends

#31

Post by jchook »

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 forced to also embrace hooks or write complicated wrappers to facilitate them, for example new component lifecycle methods (e.g. componentDidFocus).

Some things I noticed...

1. TypeScript is amazing. Combined with Intellisense it has given me coding superpowers. I can write code faster and with dramatically more confidence.

2. You can incrementally shift your JS app to use TypeScript. You can even write type declarations for your JS code without rewriting it in TS. Most of your favorite libraries already have such type definitions (see DefinitelyTyped).

3. Hooks require a significantly different mental model than PureComponent. It feels horribly wasteful at first but apparently relies heavily on JS interpreter optimizations and memoization to achieve superior FMP performance[1]. My app feels noticeably snappier now, but it took a good bit of tuning to correct issues introduced during the port.

4. It IS indeed possible to write a functional wrapper that provides otherwise unavailable hook support for your Component or PureComponent. The tricky part is that you need to use a ref to invoke lifecycle methods on your wrapped component[2].

In retrospect I think I would recommend against porting an existing React project to hooks. However I would absolutely recommend porting to TypeScript, even if you do so slowly and incrementally.

1. https://medium.com/@dan_abramov/this-benchmark-is-indeed-fla...

2. https://medium.com/reactnative/custom-lifecycle-methods-in-r...

Re: Do Not Follow JavaScript Trends

#32

Post by Grimm1 »

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.

I think you may be conflating components and good old fashioned libraries. You can certainly make a component into a library but that's not their main use case. Their main use-case is for organization and reusability within a singular codebase.

I write reusable components all the time inside my codebases. I never have to target anything except the stack I'm using for my project.

Re: Do Not Follow JavaScript Trends

#33

Post by agentultra »

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?

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.

Re: Do Not Follow JavaScript Trends

#34

Post by recursivedoubts »

no_wizard wrote: post #18
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.

There is the the HATEOAS compatible JSON-LD standard being worked on at the W3C https://json-ld.org/

Yeah, but it doesn't make up for the decade+ now that plain JSON (perhaps with the occasional URL, which still has to be interpreted correctly by client code!) has been called "REST-ful".

On top of that, JSON-LD is still mainly focused on networked object graph serialization. Unfortunately it manages to be a complex specification without providing the functionality that HTML came with out of the gates as a hypertext in an obvious manner.

HTML is a good-enough-to-great hypertext, we should probably stick with it.

Re: Do Not Follow JavaScript Trends

#35

Post by thanatropism »

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…

As an outsider, I feel like React both does too much (a virtual DOM? Aren't current web standards enough to make a flower shop website?) and too little -- there's all these terms/technologies/subframeworks that people are using like "create-react-app" and "Redux" and so on.

It's neither an overarching architecture that makes normal web technology obsolete but runs on it, like Windows 95, nor a website generator like Wordpress. Web tech confuses me thoroughly, and I read HN all day.

Re: Do Not Follow JavaScript Trends

#36

Post by recursivedoubts »

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…

I have something for you:

https://htmx.org

Re: Do Not Follow JavaScript Trends

#37

Post by BossingAround »

0az wrote: post #28

A while back, I got tired of dealing with the mess of Gatsby, Next.js, and Vuepress, so I made my own static site generator in Python. I don't want a GraphQL database for my static site. I just want something to template out my site's boilerplate, and I don't want to deal with Webpack speed, or lack thereof. One file, ~200 loc, and I understand all of it. The tentatively named Zhi works fast enough for full rebuilds…

If you didn't like Gatsby, why not simply use one of the tens of simpler static generators? Hugo is extremely popular, but also just Jekyll or something similar. You won't understand the whole codebase, most likely, but on a user level, it's literally just a "put a markdown file in this directory" type of a thing for most of these generators...

Re: Do Not Follow JavaScript Trends

#38

Post by adventured »

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…

> 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!)

A few times? You're suggesting doing that 50 or 100 times.

Adding 4.4kb an actual few times is meaningless for the end user.

Re: Do Not Follow JavaScript Trends

#39

Post by duxup »

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…

Flexbox certainly allows me to accomplish things faster / in ways I couldn't (or wasn't going to hack together with tables) before.

Is that for the user, I don't think they care, but they do get changes faster / more features because I'm not pulling my hair out over tables....

Re: Do Not Follow JavaScript Trends

#40

Post by mark_and_sweep »

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-frameworks reach maturity.

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.

Personally, I hope that server-side rendering will be the new ~old~ trend.

Post reply on HN