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

561–570 of 866 posts

Re: React is winning by default and slowing innovation

#561

Post by burnerzzzzz »

zero_shift wrote: post #504
mike_hearn wrote: post #499

Earlier quoted context omitted.

So JSX is pure Javascript and not, say, a dialect of XML embedded in JS? Because it sure looks like the former even though it compiles to the latter. React isn't Javascript. It's a franken-language that looks superficially like a mix of JavaScript and XML whilst following the rules of neither. That's why there is such a thing as a React compiler - a good sign that you're not writing JS, which doesn't have compilers.…

> So JSX is pure Javascript and not, say, a dialect of XML embedded in JS? It would be best to think of it as syntax sugar for create Element() function calls. You enter JSX with angle tags and insert expressions in braces > React is full of magic syntax that looks like functions, but e.g. you can't call them inside an if statement, or you have to redundantly declare the 'dependencies' (variables you read) and so on…

> It would be best to think of it as syntax sugar for create Element() function calls

Thats what makes it a new language. C is just sugar on top of assembly.

Its so strange that jsx needs a buildstep, but misses ton of obvious ergonomics that one could have added. Why className instead of class? With a buildstep, it would surely be possible to determine if class was a keyword or not based on context

Re: React is winning by default and slowing innovation

#562

Post by burnerzzzzz »

lerp-io wrote: post #527
mike_hearn wrote: post #499

Earlier quoted context omitted.

So JSX is pure Javascript and not, say, a dialect of XML embedded in JS? Because it sure looks like the former even though it compiles to the latter. React isn't Javascript. It's a franken-language that looks superficially like a mix of JavaScript and XML whilst following the rules of neither. That's why there is such a thing as a React compiler - a good sign that you're not writing JS, which doesn't have compilers.…

um....react is literally js and its not a language, you can write react with or without jsx which is just syntax sugar to make it look more like html.

“syntax sugar” means its a new language. It has a new syntax.

Re: React is winning by default and slowing innovation

#563

Post by bricss »

React is a pure abomination, and probably the worst thing that could happen to the web. Imagine Backbone with JSX, but w/o MVC, MVP or/and MVVM in mind. The amount of code that one needs to write even to handle simple registration form is the mind-blowing. Thanks to the lack of two-way binding support, when everything needs to be handled by hand, leading to the bloated codebase of copy-pasta of zillion of hooks. So, instead of focusing on biz logic, devs mostly end up writing scaffolding and functional logic.

Re: React is winning by default and slowing innovation

#564

Post by muspimerol »

cosmic_cheese wrote: post #93
jonny_eh wrote: post #91

Earlier quoted context omitted.

It's usually not the framework that causes apps/sites to be slow.

Not directly, but when you have devs who only know how to build with the framework and don’t have a grip on what’s going on under the hood or how it all interacts in the browser environment (increasingly common), performance is sure to take a hit.

This happens regardless of which framework is used or even if no framework is used. Plenty of web developers do not understand how the browser or JS work at a deep level.

Re: React is winning by default and slowing innovation

#565

Post by lelanthran »

palmfacehn wrote: post #473
mrinterweb wrote: post #195

I would say react being the default expands to apps that normally would work perfectly server-side rendered. The insane amount of added boiler plate associated with writing an API, tests for the API (including contract tests), API documentation, API versioning concerns, deployment timing considerations; front-end API integration, front-end state management, front-end tests, API mocks, I feel like there's about 10 mor…

Even for dashboards or other cases where the React maximalists claim that application state is too complex, it is usually trivial to inline a bit of JSON representing the initial state and handle updates with Vanilla JS. For me, I appreciate that my pages can render with one single request. There's something deeply wrong when you have the entire browser API at your fingertips, yet include 10mb of dependencies. The br…

If you dont need two way data binding you can go quite far without React, using a single general dispatch function for one way data binding.

Few use cases need two way data binding, but under React every use case gets it.

IOW with React to get the 800lb gorilla attached to the entire jungle when all you wanted was a banana!

Re: React is winning by default and slowing innovation

#566

Post by rkomorn »

burnerzzzzz wrote: post #562
lerp-io wrote: post #527

Earlier quoted context omitted.

um....react is literally js and its not a language, you can write react with or without jsx which is just syntax sugar to make it look more like html.

“syntax sugar” means its a new language. It has a new syntax.

This is the first time I've seen someone argue that adding syntactic sugar means creating a new language.

Re: React is winning by default and slowing innovation

#567

Post by patates »

WickyNilliams wrote: post #513
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…

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)

I really don't understand this colored functions debate. Async functions are just functions that return Promise 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.

Re: React is winning by default and slowing innovation

#568

Post by patates »

gloosx wrote: post #515
mike_hearn wrote: post #499

Earlier quoted context omitted.

So JSX is pure Javascript and not, say, a dialect of XML embedded in JS? Because it sure looks like the former even though it compiles to the latter. React isn't Javascript. It's a franken-language that looks superficially like a mix of JavaScript and XML whilst following the rules of neither. That's why there is such a thing as a React compiler - a good sign that you're not writing JS, which doesn't have compilers.…

JSX is just a syntax extension to JS, and it's not even required to create a React app. React "compiler" is in fact a transpiler, which is a very common thing in JS. >React is full of magic syntax that looks like functions Full of magic syntax meaning 5 straightforward hooks? Surely they are not true free-form JavaScript, but at least the syntax itself is not turned into a DSL

Nitpick: React compiler is not a transpiler. JSX needs to be transpiled, and that's usually done by TS compiler. React compiler is another optional thing on top that's relatively very recent.

https://react.dev/learn/react-compiler/introduction#what-doe...

Re: React is winning by default and slowing innovation

#569

Post by [deleted] »

sensanaty wrote: post #543
gloosx wrote: post #540

Earlier quoted context omitted.

Well, that is really embarrassing for Cloudflare... A recursion in a side-effect via dependencies is a rookie mistake, it's hard to imagine it could slip into production with a proper due process. Maybe they should stop vibe-coding and deploying things to production without any tests or review?

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…

[deleted]

Re: React is winning by default and slowing innovation

#570

Post by WickyNilliams »

gloosx wrote: post #540
sensanaty wrote: post #526

Earlier quoted context omitted.

> 5 straightforward hooks `useEffect` is straightforward? Cloudflare recently (like, literally 4 days ago)[1] had a pretty big outage because of the improper use of `useEffect` (surprise, surprise, it was the dependency array), a hook so infamous if you search "When should I use `useEffect`" you'll get approximately 9 trillion hits, with nearly all of them telling you something different, including Dan Abramov himsel…

Well, that is really embarrassing for Cloudflare... A recursion in a side-effect via dependencies is a rookie mistake, it's hard to imagine it could slip into production with a proper due process. Maybe they should stop vibe-coding and deploying things to production without any tests or review?

Disagree about it being a rookie mistake. In the simple case, yes. But consider data used by an effect could travel all the way from root to the max depth of your tree with any component along the way modifying it, potentially introducing unstable references. Maybe it worked when you tested. But later someone introduced a new component anywhere between data source and effect which modified the data before passing it on. That component may have used useMemo. So it looks ok, but it over fires.

You become reliant on all your ancestors doing the right thing, in every situation, forevermore. One mistake and unstable references cascade everywhere. The surface for introducing errors is huge, esp in a large, complex codebase. And we have no way to guarantee a stable reference.

Post reply on HN