Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React is winning by default and slowing innovation

lorenstew.art

Post reply on HN
Print view View original

771–780 of 866 posts

Re: React is winning by default and slowing innovation

#771

Post by recursive »

apsurd wrote: post #760
recursive wrote: post #727

Earlier quoted context omitted.

Over the years, I've seen a few posts like this that seem to take it as a given that a loop in a normal programming language is better than foreach capability in a template language. Certainly enough times to believe that a significant group of people actually believe it's superior. There's not a difference in capability of expression of the two models. It seems to be a purely aesthetic or comfort difference. I guess…

It's because native programming language will defacto allow you to hack it to its natural limit. A tendency most all programmers have given they even get into programming. For example with any iterator/loop you may want to filter, or find, or transform. in ruby you have the entire Enumerable API to dig into or Array prototype for js. a templating language would have to reimplement functionality one by one in an allow…

I see that as a feature.

I would rather that all the developers were "encouraged" to do the filtering and sorting in some kind of logic block rather than having an attractive footgun lying around that makes it easy to cram in one more last data adjustment.

To each their own I suppose.

Re: React is winning by default and slowing innovation

#772

Post by WorldMaker »

magnio wrote: post #589
gloosx wrote: post #472

React isn’t just "winning by default" It's winning because at the core it's just JavaScript function composition. A component is a function, conditionals are `if (...) { ... } else { ... }`, loops are `map()`. JSX is just sugar for function calls. In Svelte you are writing XML with little JavaScript islands inside it. Instead of if you get `{#if}{:else}{/if}`. Thats not "ergonomic" – thats a mini-language stapled on…

Man, I am glad I don't have to work with any developers for whom having to write "className" (which has been in the DOM standard since 2000) over "class" is a deal-breaker.

To be fair though, that's not a JSX restriction, that's a React choice. (In my own JSX-based library, I allow `class="thing"` and `for="some-id"` just fine as simple synonyms of className and htmlFor.)

Re: React is winning by default and slowing innovation

#773

Post by WorldMaker »

faangguyindia wrote: post #622
gloosx wrote: post #472

React isn’t just "winning by default" It's winning because at the core it's just JavaScript function composition. A component is a function, conditionals are `if (...) { ... } else { ... }`, loops are `map()`. JSX is just sugar for function calls. In Svelte you are writing XML with little JavaScript islands inside it. Instead of if you get `{#if}{:else}{/if}`. Thats not "ergonomic" – thats a mini-language stapled on…

off topic but react code is hard for LLM to edit for some reason compared to other like VueJS

I've found the opposite: LLMs have trained on so much React that they want to spit it out even in places where that doesn't make sense. It's been useful when working with my own JSX-based library that React output is often an okay first pass, and LLMs did help me iron out a few common React "idiom" compatibility needs that were missing.

Re: React is winning by default and slowing innovation

#774

Post by wredcoll »

imtringued wrote: post #633
conartist6 wrote: post #619

Earlier quoted context omitted.

Hooks are magic syntax without any doubt. All magic syntax is made up of non-magic parts, that's kinda the point. The way you know it's magic is it shatters the principle of referential identity, which tells you that a variable is itself. It pretends you can use a simpler mental model but you really cannot and must not.

Hooks aren't magic syntax. The problem with hooks has nothing to do with syntax. The problem is that the React crowd has decided to overload the meaning of a term that has had a reasonably solid interpretation (at least in comparison to the React crowd). "React Functional Components" have nothing to do with conventional functional programming. They inherently (intentionally?) violate the spirit of functional programm…

Please, just give me objects back. They were so much easier to reason about. I liked writing `this.stateVar`!

Re: React is winning by default and slowing innovation

#775

Post by wredcoll »

gloosx wrote: post #649
sensanaty wrote: post #543

Earlier quoted context omitted.

If after nearly a decade swarms of people are still making the exact same mistakes with how they use a specific method exposed by the library, then the problem isn't with the hundreds/thousands of people making the mistake, the design of the method is broken. This type of issue simply does not exist in Vue or Svelte even if people abuse watchers (which I've anecdotally noticed tends to happen from React devs writing…

You know for thousands of years people are still stepping on rake, the spikey part. And they get hit in their foreheads. The rake is lever by design, but I wouldn't say the problem is the rake.

A) exactly how many people in alk of history have ever actually done that?

B) rakes can't be changed to prevent that, software apis can.

Re: React is winning by default and slowing innovation

#776

Post by wredcoll »

patates wrote: post #718
the_gipsy wrote: post #707

Earlier quoted context omitted.

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.

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…

> It's like dealing with event handler registrations. You cannot compose those too, as they are "hooks" for when a specific event occurs.

Yes, and those are frequently annoying also. Literally the point of the article is the friction they introduce and questioning whether there are better ways to do things. Sometimes there are.

Re: React is winning by default and slowing innovation

#777

Post by wredcoll »

WickyNilliams wrote: post #542
sensanaty wrote: post #538

Earlier quoted context omitted.

> 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 a…

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

I miss Vue's class based syntax. It felt so nice to have all the various magical bits having an actual home.

Re: React is winning by default and slowing innovation

#778

Post by WorldMaker »

_heimdall wrote: post #296
spankalee wrote: post #200

Earlier quoted context omitted.

> the fact that you can only pass strings as attributes This isn't true at all though. It's a lie started in the early days by React engineers that just won't die, unfortunately. Web components are objects and they can have properties and accessors like any object. The vast majority of declarative template systems like React, Lit, Vue, Angular, Svelte, Solid, etc., will declaratively set properties - which can carry…

That approach passes values in JS rather than the DOM, right? I read the go comment as talking specifically about DOM attributes which can only be strings (well, you can have boolean attributes as well). Web components can be passed objects in JS, but its news to me if that is available in HTML.

If you really need the ability to pass complex objects via an HTML attribute, you can use the same thing we used in the old jQuery and Knockout days: JSON.parse().

    this.someProperty = JSON.parse(this.getAttribute('some-attribute'))

Re: React is winning by default and slowing innovation

#779

Post by austin-cheney »

brazukadev wrote: post #756
austin-cheney wrote: post #682

Earlier quoted context omitted.

How would you refactor it?

Is it some bundled code or those ~4k lines are written just for that case? You don't reuse even your own code? I would start by organizing the code in a sane and logical way. But that's why I said, if you enjoy coding this way, great.

It is arranged in objects defined as TypeScript interfaces. It can be easily broken down into numerous smaller files and be equally organized, but then the code would be in multiple places without any benefits except that there would be fewer lines in one file.

I get the impression that people who are only used to seeing front end code as JSX don't have any idea how to proceed when its just JavaScript. If they aren't also writing code outside the browser they are likely never exposed to application code in any real form because all they see is template abstractions. The reality is that it is just JavaScript which is no different in the browser compared to in Node, except for calling a different API. If this is the case then anything that isn't JSX is cause for an anxiety attack, most especially if its more than 120 lines of code.

If you are not capable of reading code then no matter of alternate guidance will matter.

Re: React is winning by default and slowing innovation

#780

Post by tracker1 »

sfink wrote: post #243
tracker1 wrote: post #20

The premise is bullshit... there were LOTS of competing options when React first came out... it wasn't really until Redux hit that a lot of people started seriously using it. A lot of the flux implementations were painful, configuring Webpack was a pain, etc, etc. It may be the default today, but it largely earned that position by being one of the better options out there. Today there's alternatives and even Angular…

> The premise is bullshit... there were LOTS of competing options when React first came out... Good thing that wasn't the premise, then. The article is specifically looking at reasons for React's success other than its technical merits. It does not deny that it has merits, nor does it deny that its success is partly due to them. It only says that its current success is no longer wholly due to them, and backs the poin…

Maybe... but it achieved that default status in the first place through a lot of technical merit. It stayed there because it's largely good enough and remains with a lot of inertia, as well as the shear size of the larger community. Just MUI, Mantine and even Bootstrap component libraries are in and of themselves very polished and generally better than any competing technologies.

If there was an MUI for Yew/Leptos/Dioxus I'd probably have switched to them and dealt with the minor performance hit with wasm. And yeah, there's component libraries, but not nearly as complete or polished in usage.

Post reply on HN