Live data from Hacker News

Why I don't miss React: a story about using the platform

jackfranklin.co.uk

211–220 of 279 posts

Re: Why I don't miss React: a story about using the platform

#211
post #198

Earlier quoted context omitted.

Depending on the complexity of your computations and state, what you just described can basically become unusable. For example, an app I work on implements a spec which: - Models state as an arbitrary DAG - With arbitrarily deep dependency chains - Which may trigger dependent nodes based on only subsets of their state - Based on computations of arbitrary XPath expressions, sometimes containing non-native extensions;…

Would love to know what the app does. From the mentions of xpath all I can think is "visual xml editor"?

ideas:

could be using data returned in XML format because there is no JSON endpoint for that particular data source.

XPath is also nice for dealing with just about any complex markup tree, for example if you needed to extract data from serialized DOMs that were sent to your application somehow.

How about SVG tools using XPath?

Re: Why I don't miss React: a story about using the platform

#212
post #102

Earlier quoted context omitted.

Does React itself have edges, or do your issues derive from other parts of the ecosystem (Redux, styled-components, MobX, whatever)?

React has edges. Hooks are an anti-pattern with all kinds of footguns. Suspense is also a crazy anti-pattern by literally throwing and catching errors as a means for communicating between parts of the framework. And this isn't an issue of me not understanding React or hooks, I would consider myself to be as expertly acquainted with hooks as it's possible to be. Now, do I still use React for everything? Yes. Do I pref…

I work primarily with React, and I'm curious - why do you consider hooks to be an anti-pattern? (This isn't a criticism, genuine curiosity)

Re: Why I don't miss React: a story about using the platform

#213
post #72
post #69

Earlier quoted context omitted.

> There is a huge amount of man-hours poured into making these frameworks work correctly under any condition. The path is littered with the ghosts of frameworks past. Don't let the current efforts or trends convince you that we're done with this process. React will be a ghost one day.

That's like saying I should use a steam engine today because the electric motor will be superseded someday.

If an electric engine makes your vehicle noticeably slower and heavier, there's a reason to keep using a steam engine.

Re: Why I don't miss React: a story about using the platform

#214

Earlier quoted context omitted.

> This will not allow you to build very rich apps without implementing a significant chunk of the frameworks you dislike so much I am currently working on an app at work that wants SPA functionality, but they won't let me use any of the frameworks. Tons of vanilla JS and Jquery. I am sure what I have written is probably considered a crime against humanity in some place. Does it work? Yes. Is it an elegant and maintai…

That raises an interesting question: what would be the declarative framework easiest to minimally reimplement? I’m thinking you could have a single file, jQuery-based, hand rolled version of some framework and get many of the benefits while still technically complying with the “no frameworks” rule. In the same way that you could reimplement Redux easily if you for some reason weren’t allowed to use it. I suspect diff…

https://zserge.com/posts/worst-react-ever/

https://zserge.com/posts/worst-vuejs-ever/

Re: Why I don't miss React: a story about using the platform

#215
post #53

Earlier quoted context omitted.

RxJS aka the reason so many websites take 100MB of memory nowadays Don't use it

It fairness you can do reactive data without RxJS. For example by using the vanilla web socket API. Agree that RxJS is best avoided though.

You can react to state changes with an astonishingly small amount of code with JS [0]

[0]: https://github.com/curlywurlycraig/vdom-util/blob/master/src...

Re: Why I don't miss React: a story about using the platform

#216

Really enjoyed this article. Web components seem promising, I played around with them a bit but I found it difficult dealing with global styling (ie, how do I make my component have the same colour scheme as everything else?). Probably worth looking into again. I also concur with the author about lit-html. It does one thing and does it really well, easy to understand, and no transpiling needed. Can't recommend it eno…

If you’re using a shadow root, look into CSS Custom Properties which poke through it and the HTML part attribute as well as its corresponding CSS :part() selector.

Reading the MDN documentation for parts, how are they different from classes?

Re: Why I don't miss React: a story about using the platform

#217
Tried Lit and StencilJS.

They are both forcing the usage of custom events to dispatch functions and share data between components. It's horribly unergonomic. Using the DOM with event bubbling and capturing feels really bad.

Orchestrating rendering is a mess.

The Shadow DOM and templates don't really solve any issues that aren't already solved with things like CSS modules for style scoping and even using element cloning is faster than templating.

The only thing they have going for it is that they're a nice way to share 3rd party components as an alternative to iframes or JS library API which targets a DOM node with a parameter.

And you can use any small framework like Preact, Svelte or SolidJS and wrap it with a web component.

Re: Why I don't miss React: a story about using the platform

#218
post #216

Earlier quoted context omitted.

If you’re using a shadow root, look into CSS Custom Properties which poke through it and the HTML part attribute as well as its corresponding CSS :part() selector.

Reading the MDN documentation for parts, how are they different from classes?

They are both DOMTokenLists so parts look a lot like classes. The difference is parts are used in a shadow root to expose internal elements for styling. I’ve written a bit about CSS parts here: https://www.abeautifulsite.net/posts/when-to-create-css-part...

Re: Why I don't miss React: a story about using the platform

#219

Earlier quoted context omitted.

React has edges. Hooks are an anti-pattern with all kinds of footguns. Suspense is also a crazy anti-pattern by literally throwing and catching errors as a means for communicating between parts of the framework. And this isn't an issue of me not understanding React or hooks, I would consider myself to be as expertly acquainted with hooks as it's possible to be. Now, do I still use React for everything? Yes. Do I pref…

I work primarily with React, and I'm curious - why do you consider hooks to be an anti-pattern? (This isn't a criticism, genuine curiosity)

I don't like them because they hide program state in innocuous-seeming function calls. Want to call useContext in a helper? It'll work, until it doesn't. Want to display a loading spinner? You'd better not have any useState calls below it. Want to see what hooks a function will use? You have to run it or go through each line of every piece of code it calls, they're not in any way declarative.

The programming paradigms I like best are declarative and make invalid or undefined behaviour impossible to represent. Hooks do the opposite: they're procedural, make it very easy to write a program that compiles with subtle errors, and don't have compile time checks to stop bad code.

Re: Why I don't miss React: a story about using the platform

#220
post #144

Earlier quoted context omitted.

> If all you need is a couple of basic forms and some basic interaction, you can do it all with vanilla JS but let's not kid ourselves This is a classic red-herring argument from developers who have not built anything complex with vanilla js. You can build rich interactions with or without a framework, you’re just making different trade-offs (conventions, learning curve, flexibility, tooling). There is a much larger…

You call the argument a red herring, then name all the reasons people use a framework over vanilla js: conventions, learning curve, flexibility, tooling. Sure, the browser apis are great and always getting better, but I don't see how that's a reason not to use the framework.

Conventions, learning curve, flexibility, tooling or just because that's what is there already and you have no decision either way :D
Post reply on HN