[HN Gopher] Why I don't miss React: a story about using the plat...
___________________________________________________________________
Why I don't miss React: a story about using the platform
Author : tomduncalf
Score : 120 points
Date : 2022-05-03 07:14 UTC (15 hours ago)
(HTM) web link (www.jackfranklin.co.uk)
(TXT) w3m dump (www.jackfranklin.co.uk)
| [deleted]
| apprewired wrote:
| > In our case, we still felt this decision was justified because
| we don't have to recreate a scheduler with all the complexity of
| React's; we can build a small, self-contained implementation that
| only implements what we need.
|
| I wish there were more details about this. Implementing a small
| scheduler seems like a monumental task and I'd love to learn more
| about how to implement a base-case.
| ng12 wrote:
| > But the web platform isn't perfect, and I suspect most React
| developers have come across a situation where you'd love to be
| able to just tweak how your component is being rendered.
|
| Honestly, I haven't. The only potential caveat I can think of is
| when you have some non-reactive legacy code you want to embed
| inside a React component... but even then React's escape hatches
| are more than sufficient.
|
| If you're really worrying about when your component renders or
| re-renders it's probably because there are other issues with your
| app.
| Tarks wrote:
| The escape hatches were one of the first things I used to
| explain why I initially liked react, called them exactly that
| too.
|
| "They're smart enough to know they're not smart enough to build
| perfect abstractions, so they do a great job but leave escape
| hatches just in case"
| Esther432q wrote:
| nightski wrote:
| The only case I have is I love to use D3 for vis. But the thing
| is it's trivial to embed D3 into a react component and either
| let react handle rendering via svg or honestly just let D3 take
| over the DOM in that component. I do this all the time and it
| works very well.
| nawgz wrote:
| I wrote my own React components using D3 to do the underlying
| math but setting up my own DOM rendering. It's ok, my
| thoughts
|
| Pros:
|
| * I have generic "zoom/pan" implemented. I did this by making
| a generic ChartContainer with 5 zones - top, right, bottom,
| left, content - and you specify just the size of the non-
| content zones (if displaying them at all) and otherwise it
| behaves responsively (i.e. CSS style on the container is
| respected in the internal math). When you scroll the
| left/content/right vertically, or the top/content/bottom
| horizontally, it virtually scrolls the other components for
| you. It also of course handles the math, each area of the 5
| is passed a DOMRect describing how big of SVG it can render
|
| * I have smart edge routing component on a graph; if you are
| doing the math yourself on how to position the SVG elements,
| you can easily describe that graph, so smart edge routing is
| free
|
| * my library has themes via CSS vars, and the components
| written in this way are obviously automatically themed
|
| Cons:
|
| * it's a bit verbose for sure, takes some small time and
| focus. After the initial investment in ChartContainer though,
| they work freaking awesome
|
| * D3 graphs often come with sweet animations and such, I
| don't have any capability to emulate this today, I hate to do
| performance-heavy things like manually doing math every frame
| in a hooks-based way, and I don't want MobX in my component
| library
|
| * you sort of lose access to the D3 ecosystem, nothing is
| free
|
| To be honest, I think I have made a top-tier Gantt with the
| smart edge routing and zoom, my Graph looks sharp too, and
| for overhead views it's super nice to be able to zoom and pan
| and show rulers on the side (imagine showing factory layout,
| or a board layout, etc). Otherwise, if you are doing more
| traditional pretty eye-catching stuff, it's not quite meant
| for that approach
| cyral wrote:
| I also went this route and used d3 for the math but my own
| hand-made SVGs for the rendering so that the DOM is all in
| "react land".
|
| You may want to check out this library:
| https://airbnb.io/visx/ They converted a ton of d3 features
| into proper React components
| whimsicalism wrote:
| Does d3 have a typescript wrapper?
| dmitriid wrote:
| Everything on the web "uses the platform". There's no other way
| to get content into the browser.
|
| Web Components are just a part of that platform, and very badly
| designed at that. A lot of the platform around them now exists
| only to patch holes in them (like form participation) and to
| solve the problems they introduced.
|
| And since they are now a part of the platform, they poison
| everything like upcoming CSS scoping which instead of being a
| straightforward thing now has to account for all the web
| component insanity.
|
| _Edit_. There also so many thing wrong in the article that argh.
|
| "We don't need React and dependencies"... and then talks about
| lit-html which is a small framework with custom syntax and
| constraints on how you can use tagged literals.
|
| "Easily replaceable dependencies"... and again talks about lit-
| html which is a fully incompatible replacement for Polymer. I
| wonder how folks that used polymer (Youtube) feel about "easy
| replacements".
|
| "Can't control rendering with React" and talks about Web
| Components which literally give you no control over when a
| component can be rendered, don't have lazy loading, cannot
| subclass SVG or embed partial SVG etc.
|
| And so on and so on...
| [deleted]
| daok wrote:
| The rendering part resonate with me. I've tried in some side
| projects SolidJS framework and I really enjoy that the rendering
| of each component occurs once! Easier to not fall into some traps
| that React has.
| tentacleuno wrote:
| > Easier to not fall into some traps that React has.
|
| Honestly once you get used to it, it becomes second nature...
| For me at least.
|
| One piece of advice I would give is to not try to ram the hooks
| use-case into things. It becomes especially annoying when
| you're dealing with asynchronous values, where you need to deal
| with 'null' and friends. Sometimes some imperative code in
| useEffect is simpler to read and easier to maintain; it's fine
| to step out of the paradigm for some things.
| TAKEMYMONEY wrote:
| > Was this slightly more work than using a library from npm?
|
| > I'd definitely recommend using a library for this, and we
| settled on lit-html _(link to library from npm)_
|
| This article is mostly about switching from React to Lit. You can
| use modern web APIs (like FormData) _with_ React, FormData 's not
| a replacement for state management.
|
| You can use Web Components _with_ React, the way Fluent UI does
| (https://docs.microsoft.com/en-us/fluent-ui/web-
| components/in...).
|
| In this single case they replaced a couple validation functions
| with attributes. Good to move that direction but if that's all
| you use React for then yeah, you might not miss it much.
| Bellend wrote:
| Anyone know what is going on with lit-? Their TypeScript
| starter is painfully bloated and outdated and never seems to
| keep pace. I actually ended up looking at microsoft/fast for my
| use case but that seems to be stale in some way.
|
| I kind of feel that given the "simplicity" of a single class
| wrapping custom elements, everything is pretty boring.
|
| Note: I cannot do better.
| LAC-Tech wrote:
| Can't speak for the Lit framework, but never had any issues
| with lit-html or it's typescript defs, it's been rock solid.
| claytongulick wrote:
| I'm in the same boat.
|
| I don't use lit-element, it's too heavy for me.
|
| lit-html, on the other hand, is wonderful and rock solid.
|
| I typically do light dom components, rendered with lit-
| html. Simple classes that extend HTMLElement.
|
| When I want reactive style, I add setters that call
| render(). When I want imperative, I add class functions.
|
| All my components generally take care of themselves and are
| mostly encapsulated, they'll generally have a init() method
| that loads the data they need, and calls a setter which
| kicks off the render cycle.
|
| Alternately, data will be passed from a parent component
| via a property, and that'll also kick off the render cycle.
|
| In many cases I do a combination of the two in order to
| support deep linking.
|
| I'll mix and match design systems sometimes, depending on
| the payload weight. Ionic, shoelace, etc...
|
| The Vaadin router ties everything together beautifully.
|
| I also have a small state utility called
| ApplicationState[1] that I use for the edge case of cross-
| component communication and triggering. It provides a
| graph-based approach to notifications/state change.
|
| I've been using this approach for several years with
| success, with deeply complex and large applications and
| small lightweight tiny footprint apps.
|
| [1] https://claytongulick.github.io/applicationstate/
| kall wrote:
| I feel like google does web component frameworks like it does
| messaging apps. Each new one is the silver bullet. I wouldn't
| build on any google web framework personally, even if it
| claims to be oh so simple and lightweight.
| Bellend wrote:
| I been looking since Polymer and appreciate the history
| (polyfills, change of direction from other W3 holders etc).
| I agree but Lit Element still seems a contender but also
| seems that few people work on it.
|
| An example is that I have a basic scorebox. It's
| essentially a div with custom styling, used across 100
| games, has language support, updates in real time and
| everyone should be using it.
|
| npm install @mycompany/score-databox
|
| This is how you use it... this is how you integrate with
| all games.... etc. It's so basic that it rarely changes.
| The API is the same everywhere etc etc.
| ummonk wrote:
| It's bizarre to see the author waxing poetic about the small size
| of lit-html when it's actually no smaller than Preact.
| mappu wrote:
| lit-html is great although at $DAYJOB we ran into some issues
| with missing linting on them.
|
| We now use a JSX renderer that emits plain HTML strings.
|
| You get all the ergonomics, the IDE assistance of checking for
| typos in your attributes, ensuring your closing tags line up, and
| webpack can flatten it back to plain HTML at compile-time for no
| run-time __jsx / React.createElement() calls.
| _pdp_ wrote:
| 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 will not allow you to build very rich apps
| without implementing a significant chunk of the frameworks you
| dislike so much. In fact, I would even say that if this is not a
| core part of your product, you are simply wasting time and
| resources. There is a huge amount of man-hours poured into making
| these frameworks work correctly under any condition.
| otikik wrote:
| > of the frameworks you dislike so much
|
| This is totally uncalled for. He's not attacking you. He's
| explaining a tradeoff, very reasonably.
|
| > I would even say that if this is not a core part of your
| product, you are simply wasting time and resources.
|
| I find especially interesting that this phrase can be used to
| defend _both_ sides of the argument. If you are building a
| highly rich application, chances are that using a framework for
| that is the right choice, agreed.
|
| But.
|
| Not all the apps being build out there need to be Very Rich
| Apps. There's indeed a lot of space for only-slightly-rich-but-
| mostly-static apps, despite the recent HN article.
|
| And for those, introducing a framework is ... precisely, a
| waste of time and resources.
| klodolph wrote:
| > This is totally uncalled for. He's not attacking you. He's
| explaining a tradeoff, very reasonably.
|
| What? I don't see how "dislike" would describe anything other
| than some kind of preference. I don't see how it's an attack.
| samhw wrote:
| Their comment is perfectly reasonable and measured. I don't
| think anything in it is 'uncalled for'. Your own comment is a
| confusingly ironically ill-tempered response.
| LAC-Tech wrote:
| I think react sits really well with some people, and with
| others it doesn't. For me I find I have to fight against the
| platform to separate presentation from behaviour. And let's not
| kid ourselves, a lot of react code bases do the classic
| winforms mistake of having an essentially code behind
| architecture.
| datavirtue wrote:
| And why was that a mistake?
| [deleted]
| interlocutor wrote:
| React works well for simple, non-interactive components. Complex,
| interactive components are going to have state. Stateful
| components don't work so well in React. If you want to update
| props in a stateful component, the recommendation is to replace
| the component entirely by changing its key. At the point all of
| the benefits of React (preservation of selection, caret position,
| scroll position etc.) vanish. You might as well use vanilla js
| instead of React.
|
| What does using Vanilla JS look like? Here's an example:
| https://github.com/wisercoder/eureka It uses two tiny 500-line
| libs. It uses TSX files, just like React. It has components, just
| like React. It doesn't have incremental screen update, but
| neither does React, if your components are interactive and
| stateful.
| kall wrote:
| Wait isn't state the whole point of react? What level of
| interactivity are you talking about? State and props, that's
| it's thing: you can always update them.
|
| I've only need the "change key to flush components" trick very
| few times, and most of those where rush fixes for bugs that had
| a better "doing it right" fix at a different level.
| Jcampuzano2 wrote:
| This is categorically false. If you want to update props in a
| stateful component it is exactly the same - just pass new
| props.
|
| If you instead are talking about syncing props with state,
| there are ways to do this as well without changing the key, but
| this is considered an anti-pattern in the first place.
|
| This sounds more like bashing react without even knowing it
| very well in the first place.
| kikki wrote:
| This is either a fundamental misunderstanding of React, or
| you're actually talking about a different library.
|
| > React works well for simple, non-interactive components.
| Complex, interactive components are going to have state.
| Stateful components don't work so well in React
|
| React components are designed with state in mind. When state
| changes, components passed that state in the form of props are
| re-rendered. Don't take my word for it though, from the first
| paragraph on the reactjs.org website; "React makes it painless
| to create interactive UIs. Design simple views for each state
| in your application, and React will efficiently update and
| render just the right components when your data changes."
|
| > At the point all of the benefits of React (preservation of
| selection, caret position, scroll position etc.) vanish.
|
| I have never heard these spouted as the benefits of React. The
| main fundamental philosophy of React is that only components
| that have state changing "react" to changes - in other words,
| the benefits of React are: no unnecessary re-rendering (hence
| the virtual DOM).
|
| > If you want to update props in a stateful component, the
| recommendation is to replace the component entirely by changing
| its key
|
| This part just threw me, if you are doing it this way - you are
| doing it wrong.
| tentacleuno wrote:
| > Stateful components don't work so well in React. If you want
| to update props in a stateful component, the recommendation is
| to replace the component entirely by changing its key.
|
| Do you have any concrete examples for this? I'm not sure I
| agree: I've made plenty of stateful components in React and
| they are just fine. If anything, they're a lot cleaner than
| what I could do in plain JavaScript, thanks to the framework.
|
| Further, could you expand on what you mean re: recommending
| changing the key? I have never heard the React team suggesting
| to do this, although maybe I missed something in the
| documentation :-)
| zelly wrote:
| The problem with Web Components is it's slower than React or
| other vDOM implementations. Also everything is a string. To re-
| render, you have to manipulate the innerHTML--usually replacing
| the string every update. To pass a prop to a component in a
| modular way, you have to pass a string attribute (e.g. something
| like <my-component my-attribute="[1,2,3]"/>). Even though v8 is
| extremely fast at string operations, it's just not a good
| practice and doesn't scale.
|
| W3C standardized Web Components before React existed and took
| off, unfortunately. I expect the next standard to just be React
| itself (or a barebones version that the library can build on top
| of), patent licenses permitting. I'm pretty sure as a C++
| precompile, it would be unstoppable and end the debate for good.
| brundolf wrote:
| > Web Components is it's slower than React or other vDOM
| implementations
|
| > To re-render, you have to manipulate the innerHTML--usually
| replacing the string every update
|
| "Usually" is relative, I guess, but nothing's stopping you from
| using the imperative DOM APIs to update the component's
| contents; I daresay this would be the typical thing to do.
| These APIs will be just as performant as anything else out
| there. What you're really giving up, then, is the reactive
| programming model. Web Components are just a way of
| modularizing things; they have nothing to say about how you
| update the DOM (for better and worse).
| zelly wrote:
| If you're using a framework like lit-html as the author
| recommends, it will replace the string every update. Most
| people will prefer that way since it's more ergonomic and
| similar to React. You could do imperative DOM updates, but
| that'd be like going back in time to jQuery.
| brundolf wrote:
| Right, all I'm saying is this is nothing intrinsic to the
| Web Components standard like the parent comment suggested.
| It's just one particular way you might use them.
| LAC-Tech wrote:
| 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 enough for generating dynamic html
| client side.
| claviska wrote:
| 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.
| bobertlo wrote:
| My ad for web components: btw I used to use react
| [deleted]
| lcnPylGDnU4H9OF wrote:
| > Firstly, because some people on the internet like to get
| angry over opinions that may not match their own, I want to
| make clear what this blog post is not:
|
| > It is not a call for everyone to immediately drop React and
| move to web components.
|
| > It is not a blog post declaring React "dead", or the wrong
| choice for every project.
|
| > It is not a blog post declaring web components the best
| solution to all projects.
|
| You might want to consider how well the phrase, "Haters gonna
| hate," applies to your comment.
| lozenge wrote:
| The author makes some fair points but I also think part of it is
| learning. It sounds like they had finished learning React and the
| ecosystem and all that was left was finding React bugs, and
| occasionally identifying ways to work around React's way of doing
| things. While they are still at a stage of learning Web APIs
| which means exciting discoveries.
| v0idzer0 wrote:
| Yeah agreed. The arc of learning seems to be...
|
| This is interesting -> this is the best thing in the world ->
| here's how this could be better
|
| The "use the platform" people have been making this case for
| web components for at least 5 years now. The reality is WC will
| take off when and if they are a better alternative and even
| then they'll need to be paired with some sort of framework.
| They may even make their way into React one day.
|
| The only thing that bugs me about these takes is React is using
| the platform. It works great in all major browsers, it's not
| some extension like Flash. It's the platform.
| LAC-Tech wrote:
| React very much feels like its own platform to me - having
| its own browser tools to debug it is a dead giveaway.
| kall wrote:
| The section about trusting dependencies, the scenario where they
| go away, version churn etc doesn't resonate with me in regards to
| react.
|
| I don't know any project in JS-land that is more serious about
| semver, backwards compatibility and reliable upgrades than react.
| If facebook dropped the project tomorrow, Vercel alone could
| probably continue to maintain it well.
| mathgladiator wrote:
| I'm moving towards vanilla JavaScript for my platform, and one of
| the things that I've discovered is that if you have a reactive
| data source then you don't need a lot of framework. Granted, I'm
| taking advantage that the core platform is much more stable than
| a decade ago.
| throwaway894345 wrote:
| What is a reactive data source?
| mathgladiator wrote:
| A data source that you subscribe to and get a stream of
| updates. I'm building https://www.adama-platform.com/
| bern4444 wrote:
| I imagine a webhook source could be a reactive data source or
| any stream based API
| sibit wrote:
| To me a reactive data source would be something like Asana,
| Trello, Teamwork or on an ecommerce site it could be the cart
| widget. Basically any type of data that needs to react
| without requiring a page reload or any data source that needs
| to sync with another users inputs in real time.
| zelly wrote:
| RxJS aka the reason so many websites take 100MB of memory
| nowadays
|
| Don't use it
| rglover wrote:
| Come on over rovers: https://github.com/cheatcode/joystick.
|
| I promise you'll love it if you're switching from React (pure
| HTML, CSS, and JavaScript w/ minimal abstraction). And it's full-
| stack so no more stitching together frankenstacks. Good ol'
| isomorphic JS for devs who value their time/productivity.
| andrewstuart wrote:
| There's pointers here to interesting new things which I'll have
| to learn more about.
|
| One of the core values for React for me is simply code structure
| - organising things into a hierarchy of elements seems to make
| sense - I found that hard to replicate when I once tried to build
| a vanilla js application.
| k__ wrote:
| Aren't web components more of an addition to frameworks like
| Bootstrap than a React replacement?
| zelly wrote:
| Correct. The best use case for Web Components is to ship a
| bloat-free, reusable widget that doesn't care whether a
| consumer uses it with React, Vue, vanilla JS, Angular, etc.
| Bellend wrote:
| I don't think so. I want to wrap webgl games with a custom
| component, and they share basic UI (which are also custom
| component dependencies). But none of this has anything to do
| with the larger web application (Angular) which manages much
| much more.
|
| So stuck with iframes which although I can hide to some extent,
| are terrible.
| k__ wrote:
| But React does much much less than Angular.
| Bellend wrote:
| I am not meaning it like that sorry that I did not explain
| well. There is a place for frameworks, and there is a place
| for "wrapping" non framework projects as a consumable. I am
| stuck here. I just meant that any framework or not is
| optional. React, Angular, Vue, Svelte or my funny.html
| should be able to use my "bundle" with options because the
| "bundle" doesn't care. That is where Custom Elements shine.
| It's just that from my perspective, Angular is the
| interface to the project.
| rexpop wrote:
| It seems that the author switched from Facebook's React to [his
| employer] Google's [Lit](lit.dev), and subsequently wrote a blog
| post in praise of _the hand that feeds_.
|
| > Replacing lit-html would be an undertaking but much less so
| than replacing React: it's used in our codebase purely for having
| our components (re)-render HTML.
|
| That's high praise. I might take a second look at Lit and style
| it facilitates.
___________________________________________________________________
(page generated 2022-05-03 23:00 UTC)