Hooks are very much not normal functions though. They are a new "colour" of function much like async functions - they can only be called in components or other hooks, they cannot be called conditionally, cannot be called in loops etc. The so-called "rules of hooks"

(To get ahead of the common objection: of course it's still JavaScript by virtue of being implemented in JavaScript. But so are Svelte, Vue et all)

▲

patates 6 hours ago | parent | next [-]

I really don't understand this colored functions debate. Async functions are just functions that return Promise<T> instead of T. You can use them in a non-async function but you must then switch to callbacks, because you hold a promise. I don't get how this is confusing, unless you define the whole concept of concurrency in a single thread that runs your UI as well confusing.

Hooks are functions that need to be called before early returning, in a function that provides a context for them. They are also just Javascript, they can be implemented with no build tools.

▲

WickyNilliams 6 hours ago | parent [-]

It's not confusing. It's an observation on their nature. The colouring isn't specific to promises, or even async/await. It applies to continuation style callbacks too.

If you haven't, I recommend reading the (original?) article https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

▲

patates 6 hours ago | parent [-]

I read the original article and many surrounding discussions & follow-up articles. Not confusion perhaps, but many see it as friction, including the complaints from the original article. From where I'm looking at, it's just a side effect of dealing with concurrency with no threads, what the article also mentions. So, you know, it is what it is, at the end? Now we have people coming up with different definitions of color (react hooks, in your case) and complaining that it's bad?

This is like when you are doing embedded programming, holding the API functions you need to call in a special sequence to the same standard as people writing their own DSLs with templates.

▲

the_gipsy an hour ago | parent | next [-]

The complaint is that it's not just "function composition" (per GP) at all anymore. You're dealing with "component lifecycles". Composition doesn't really work out with hooks, for reference see any non-toy React codebase.

	▲	patates 43 minutes ago \| parent [-]
		It's like dealing with event handler registrations. You cannot compose those too, as they are "hooks" for when a specific event occurs. Hook definitions can be a composition of reusable functions and other hooks, like any event handlers (e => filterKeys('cmd+s, ctrl+s', preventDefault(e)).then(save)). It's possible to break this anology (you can register an event handler in an if branch) but I hope it gets the point across.

▲

WickyNilliams 5 hours ago | parent | prev [-]

I'm not complaining it's bad per se. As I said, it's an observation on their nature.

I would not say it's a different definition of colour. I am somewhat contorting the original definition in the article, but if you compare characteristics listed, many/most of them apply to hooks also

▲

gloosx 7 hours ago | parent | prev [-]

Surely they are not normal JavaScript functions, but at least the syntax itself is not turned into a DSL like we see it in Svelte or Vue. That is the main difference.

▲

WickyNilliams 7 hours ago | parent | next [-]

Yeah I get it. I don't think the "Just JavaScript" label can be applied to react anymore. It held in a class-based world. But it's not true post hooks.

I always hated templating languages

> Greenspun's {{rules.length | ordinal}} rule:

> Any sufficiently complicated templating language contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of the host language

But after working with Vue for a 18 months and expecting to hate it, I actually very much enjoyed it. The biggest downside is strictly one component per file.

Edit: in case I've come across as some kind of react hater, I was an early adopter and still use it professionally to this day

▲

sensanaty 7 hours ago | parent [-]

> Any sufficiently complicated templating language contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of the host language

Agreed, and Vue does it right exactly because they don't let you do complex things in the template. You can use ternaries in a pinch, but `computed`s exist so there isn't even a reason to do stuff like that. There's like... 10? directives that you can use and they are extremely obvious as to what they're doing, and the handlebar syntax itself is extremely limited and doesn't let you do any crazy stuff with it.

	▲	WickyNilliams 7 hours ago \| parent [-]
		Yeah I was surprised, how little I felt hampered by its templating language. With things like handlebars and Jinja you often hit a wall like "how the hell do I express this in this language?", but never experienced it with vue. Aside: I wish other frameworks would steal Vue's event modifiers. Doing things like `@click.prevent` or `@keyup.prevent.down` is so nice

▲

hasanhaja 7 hours ago | parent | prev | next [-]

Syntactical preferences are subjective though and are prone to familiarity bias. I started my webdev career with React so I'm really familiar with JSX and like it, but that alone isn't enough to make engineering decisions.

I think semantics could be a more objective way to assess the DX of frameworks because you can have/add a syntactic layer on top that suits your preferences [1]. Semantics would be things like rules of hooks, footguns of `useEffect`, component level reactivity rather than fine-grained reactivity, etc. The high level outcome of this would be being able to answer the following question:

"How likely is it that this framework will put me in the pit of success with minimal overhead?"

[1] https://vuejs.org/guide/extras/render-function.html#jsx-tsx

▲

thedelanyo 6 hours ago | parent | prev | next [-]

I can create a .svelte file and I can just write only just hmtl - prolly a block of texts within a p tag.

With jsx, I don't think it's possible - I need to return it.

So even if Svelte is a DSL, to me it feels closer to web standard and jsx

▲

baxuz 6 hours ago | parent | prev [-]

Which is arguably worse, because syntax comes with expectations. The way React (and JSX by extension) works is effectively a bunch of overloaded macros, that depends on the pragma used.

And god help you if you want to mix component level code inside React-land and "vanilla". They had to add 3 new hooks over the last 5 years to try and alleviate those issues, all while gaslighting the community and tool authors that the were "holding it wrong".

SolidJS is far better when it comes to how well it follows expectations, and how well it integrates.