21 ms·

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

334 points by tomduncalf 4y ago

mathgladiator 4y ago
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 4y ago
  What is a reactive data source?
  - bern4444 4y ago
    I imagine a webhook source could be a reactive data source or any stream based API
  - sibit 4y ago
    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.
  - mathgladiator 4y ago
    A data source that you subscribe to and get a stream of updates. I'm building https://www.adama-platform.com/ https://www.adama-platform.com/
  - zelly 4y ago
    RxJS aka the reason so many websites take 100MB of memory nowadays Don't use it
    - nicoburns 4y ago
      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.
      - djrockstar1 4y ago
        I got into RxJS cause I had to deal with an Angular project a few months ago, what's wrong with it?
      - cnity 4y ago
        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/utils/atom.js https://github.com/curlywurlycraig/vdom-util/blob/master/src...
        thoughtpalette 4y ago
        Link doesn't work for me. 404s
        cnity 4y ago
        Apologies, should be good now.
lozenge 4y ago
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 4y ago
  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 4y ago
    React very much feels like its own platform to me - having its own browser tools to debug it is a dead giveaway.
    - v0idzer0 4y ago
      I think it feels that way because it’s a bit of a paradigm shift in terms of the way we think about building user interfaces, but the reality is its just javascript running in a browser. I’ve been writing react over 10 years and used to devtools just a handful of times. They’re by no means necessary. I used to use an extension for jQuery to quickly find css selectors. Nobody was saying we weren’t using the platform then. It’s just a strange form of posturing from web component enthusiasts who are frustrated they aren’t taking off. And these enthusiasts are 99% Google employees who work on web components.
      - LAC-Tech 4y ago
daok 4y ago
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 4y ago
  > 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.
bobertlo 4y ago
My ad for web components: btw I used to use react
- lcnPylGDnU4H9OF 4y ago
  > 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.
  - bobertlo 4y ago
    I was only joking that the title of the piece seemed slightly misleading/baiting! (but I also was not familiar with the term "using the platform")
- deleted 4y ago
  [deleted]
_pdp_ 4y ago
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.
- youngtaff 4y ago
  Jack builds Chrome DevTools, that's a really rich app and seems to work pretty well
- otikik 4y ago
  > 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 4y ago
    > 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 4y ago
    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.
ng12 4y ago
> 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.
- nightski 4y ago
  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 4y ago
    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
dmitriid 4y ago
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 4y ago
  [deleted]
- e111077 4y ago
  > talks about lit-html which is a fully incompatible replacement for Polymer. lit-html is completely different from web components and not meant to replace Polymer. lit-html is a library that just handles rendering and lit-element, which is meant to replace polymer uses lit-html as its renderer to make web coponents.
  - dmitriid 4y ago
    Semantics. If you go to Polymer website, it says this: "The Polymer library is in maintenance mode. For new development, we recommend Lit", and it links to what literally everyone I've seen calls lit-html (because that's how it started). React is also just a library that handles rendering. But sure, "it's different".
TAKEMYMONEY 4y ago
> 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/integrations/react 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 4y ago
  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 4y ago
    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 4y ago
      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/ https://claytongulick.github.io/applicationstate/
andrewstuart 4y ago
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__ 4y ago
Aren't web components more of an addition to frameworks like Bootstrap than a React replacement?
- Bellend 4y ago
  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__ 4y ago
    But React does much much less than Angular.
    - Bellend 4y ago
      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.
- zelly 4y ago
  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.
deleted 4y ago
[deleted]
apprewired 4y ago
> 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.
- timfsu 4y ago
  Not OP, but if you're building a small scheduler for batching changes, it should be pretty straightforward: - `jobs` is an array of functions - enqueue adds a job to `jobs` and starts running jobs if not running - job running can be triggered by animation frames or setTimeout
interlocutor 4y ago
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 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.
- tentacleuno 4y ago
  > 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 :-)
- kall 4y ago
  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 4y ago
  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.
LAC-Tech 4y ago
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 4y ago
  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.
  - xigoi 4y ago
    Reading the MDN documentation for parts, how are they different from classes?
    - claviska 4y ago
      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-parts/ https://www.abeautifulsite.net/posts/when-to-create-css-part...
- wrnr 4y ago
  I've come to the conclusion that web components (with or without shadow roots) are not the best "elementary particle" to build a webapp out of. Most of the time you want simple divs and sometimes you want custom-tag. The important thing is to have a setup where you can quickly promote a component into a web component proper. I think solid.js has a nice solution this, where you just call a function that wraps the component into a web compoent and registers a tag for it. One issue I have with lit is that it just forces you to turn everything into a web component instead of a carefully deliberated choice.
rglover 4y ago
Come on over rovers: https://github.com/cheatcode/joystick 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.
- oorza 4y ago
  Hard to say it's a good sell coming from React when the component API has been twice-replaced by better options in the React world. This looks awfully tedious to use.
  - rglover 4y ago
    Tedious? It's as straightforward as you can get (by design). React has devolved into an utter mess of ambiguous patterns and unnecessary abstractions that make the work far more difficult than it needs to be.
rexpop 4y ago
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.
ummonk 4y ago
It’s bizarre to see the author waxing poetic about the small size of lit-html when it’s actually no smaller than Preact.
- e111077 4y ago
  FWIW preact is 4kb minzipped (+ 700 bytes for htm package templating) while lit-html is 3.3kb minzipped. Author also talks a lot about the issues with losing control of the component model when using preact
mappu 4y ago
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.
- e111077 4y ago
  Not sure if you're aware of it, or saying it's missing features, but lit-analyzer adds compile-time linting and type checking while lit-plugin provides IDE integration of the tool
zelly 4y ago
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.
- semiquaver 4y ago
  Every real world use of Web Components that I’ve seen uses <template> elements and/or imperative DOM methods to implement rerendering. These are blazing fast and exactly what React uses. It’s possible to build a slow app using Web Components, but that’s true of every library, including React.
  - Izkata 4y ago
    Same here; I suspect they've mixed up defining the component (where some examples do use innerHTML) and using the component (which don't).
- brundolf 4y ago
  > 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). You are right (I think) that there's no good way around converting attributes to and from strings, though the performance overhead there should be minuscule in most cases. The bigger problems with that are a) some data (like functions) can't be serialized at all, and b) it leaves a lot of room for passing invalid values
kall 4y ago
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.
- sebmellen 4y ago
  Not only that, but so many strong engineering orgs build on React that I can't imagine it degrading very soon. Even if the top contributors left, Facebook imploded, and Airbnb disappeared, I'm quite certain there would be a crowdsourced effort to rescue and maintain the framework.
  - qudat 4y ago
    There’s even preact which is similar to react but a different org.
jrochkind1 4y ago
I admit I don't really understand the web components/cusotm elements "story". (I'm not even totally sure the right terminology, or what OP is talking about specifically). Are these now useable on any contemporary browser? Or do you use some kind of polyfill? Anyone have a good from-zero tutorial for the approach OP is talking about?
- semiquaver 4y ago
  Yes, they are usable without polyfills in any modern browser. The general idea is that you can register new element types whose behavior is defined in JavaScript classes. They interact with the rest of the DOM in the same way other HTML elements do: by emitting and handling events. They can also maintain a “shadow DOM” with its own HTML subtree and CSS scope, so that you can make complex elements whose internal state is encapsulated from the rest of the DOM.
  - protocontrol 4y ago
    Hi. Sorry I couldn't parse that without a specific example. In which typical use cases should I create new element types?
    - cube00 4y ago
      Whenever you'd usually create a new component in React.
    - mhoad 4y ago
      This might be a good introduction from the Lit team themselves to see what this looks like in practice https://youtu.be/QBa1_QQnRcs https://youtu.be/QBa1_QQnRcs
deleted 4y ago
[deleted]
FpUser 4y ago
I use plain JS, couple of libs and web components for business front ends. Works like a charm. Never needed React. It was created by FB to solve FB problems. Being small company this React approach to me it is just plain overhead.
didip 4y ago
Whenever I see a few internal apps made with React/Vue, they would miss super basic features such as highlight-able text or canonical permalinks. It got me thinking, why these frameworks make simple things difficult? Note that I am a backend/infra engineer (but I am able to build complex web app using jQuery back in the old days.) so I may be missing something here.
darepublic 4y ago
I have known about web components for some time but this article and the linked mdn guide have whet my appetite to maybe give it a try. Perhaps for my next bespoke small web app I can try my hand at web components rendered server side.
wrongandrew 4y ago
Both React and Lit's approach (that requires schedulers and user uncontrolled updates) are completely unnecessary for most if not all of the applications currently using React and I bet nobody even knows why they exist. Facebook made React like this because of these requirements: they wanted their chat application that requires various real time small updates to multiple parts of the page to run quickly where a wipe and rerender approach is too slow, while being declarative because their constantly rotating staff had trouble writing it imperatively. To meet this requirement you need: a constantly revolving staff that are of varying degrees of competence and can't write non-buggy imperative code in the few situations you can't just wipe and re-render a situation in your application where wipe and re-render is too slow, AND the situation is too complex to hand-write the individual updates manually The other decision React made that was wrong was the need for JSX. They decided on JSX because they made a mistake many people make when just using the pure JavaScript API for creating components - they tried to make it nested like html using a fluent/chained call approach. As it turns out, trying to keep the nested HTML structure is not necessary for readability. My library is github.com/thebinarysearchtree/artwork After using it, it makes React look like SOAP vs JSON. It has less code, runs as fast as you can get, and everything is in your control because it is just web components with some functions to handle the repetitive parts.
- djbusby 4y ago
  Would love to see some comparison between yours and React, Svelte, Riot, Angular and Vue (or others)
  - deepstack 4y ago
    For comparison, just read this: https://mithril.js.org/framework-comparison.html https://mithril.js.org/framework-comparison.html Personally I prefer mithril or Soild over all other front-end framework. They light and fast. And Mithril author had in depth knowelge of the other frameworks.
- mattwad 4y ago
  This actually looks really nice
bfz 4y ago
Article makes a variety of already well understood points, but only briefly touches on the most interesting one (from my perspective): durability. If the thing you're integrating is an evolving, improving moving target, and it's coming out of a team of only a handful of people, double any visible costs associated with your application for the sucker who must build it in 2 years time to add some new feature. It is possible to build a strong and easy to communicate case for avoiding frameworks using long term maintenance costs as the basis. jQuery was actually pretty good at this, it only had one big flag day that I can remember. In that sense, jQuery was much closer to what you get for free working directly against the platform interfaces. Deprecation cycles are much, much longer, and burden of proof much higher for new features in the browser than pretty much any third party framework. Somewhere here on the thread there was slander directed at Closure Library / Compiler. In this context, that is so totally tone-deaf, Closure Compiler/Library projects from 2010 still build with little to no changes today (based on local experience). I can't say the same for any alternative I have used in the past decade.
- dmitriid 4y ago
  > but only briefly touches on the most interesting one (from my perspective): durability React is over 10 years old and is backwards compatible probably all the way back to its 0.x versions. Web Components have already deprecated and removed v0 of Custom Elements, and deprecated HTML Imports. On framework/library side: Polymer 1 wasn't compatible with Polymer 2 IIRC, and then Polymer was scrapped and discontinued in favor of lit. React is a surprisingly safe bet for durability.
jwmoz 4y ago
Server side rendering ftw
- jpkeisala 4y ago
  I have been waiting Server Side rendering to come back. I can't get my head around why build a normal brochure website using frontend frameworks.
stanislavb 4y ago
Same here. I've been slowly getting rid of old React components on both SaaSHub & LibHunt. It's much easier to go forward and maintain your code when there's less JS complexity. For the curious ones - these are both Ruby on Rails based projects.
robertlagrant 4y ago
I've really enjoyed using HTMX + Flask rendering HTML. It seems very ergonomic.
likortera 4y ago
This reminds me of those posts like "Flask is better than Django". Sure, if you want to reinvent 90% of what's given to you for free with the bigger framework.
rochak 4y ago
I wish I didn’t say this but I just hate using React now. What was once simple is becoming more and more complex and I wish I had just stuck to a more batteries included framework like Angular/Vue/Svelte but the time has passed now. I’m just glad I don’t have to work on Frontend anymore.
- k3liutZu 4y ago
  I mean it seems you don't really like Frontend — not specifically React
ge96 4y ago
Few things that annoy me about react are mostly minor personal missed details like stale state in websockets, sometimes asynchronous state updates/wrong order; things you expect to work in a certain way but don't. Then it's like "you should use a [use]Reducer for that". Generally I like react/my go to. Just sometimes it does things not intuitive to me.
fbn79 4y ago
In my projects I use cycle.js/snabbdom and I'm already following many suggestion of the article (es. form data). My next goal would be to discard snabbdom (and virtualdom) and use custom elements. For that I'm evaluating a library like https://github.com/WebReflection/uhtml https://github.com/WebReflection/uhtml and all it's ecosystem of utility
baxuz 4y ago
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.
- WA 4y ago
  So what do you do? Hand-craft Web Components?
  - dtagames 4y ago
    In Lit, yes. It's hand-crafted web components with support for one-way data binding by parameter passing. Any other updates are by event notifications, as the commenter said.
    - WA 4y ago
      Ah thanks for clarifying, it sounded like you wouldn't recommend either Lit or Stencil.
      - dtagames 4y ago
        Sorry if I wasn't clear. I'm a huge fan of Lit! It gives you the freedom to make your own framework -- the parts you need. I respect the OP's comment and our difference of opinion, which is why I didn't reply negatively to it.
  - baxuz 4y ago
    I avoid using them, except when having to expose a component to a third party, if they _really_ want the ergonomics of using WCs. Then I'd use something like https://github.com/preactjs/preact-custom-element https://github.com/preactjs/preact-custom-element, https://stenciljs.com/docs/custom-elements https://stenciljs.com/docs/custom-elements or https://github.com/solidjs/solid/tree/main/packages/solid-element#readme https://github.com/solidjs/solid/tree/main/packages/solid-el.... As far as I see, there is nothing that WCs provide which isn't already solved, in a better way, both for devs and users. And making a framework that use custom elements and shadow DOM for component-based logic and encapsulation seems like a purely philosophical approach to adhere to some vision of "platform purity".
iveqy 4y ago
All comments is about developer experience. What about user experience? I find many framework adding a lot of data, loading times, etc. for little gain for the user.
KaoruAoiShiho 4y ago
Why lit-html over something like pug?
lysecret 4y ago
It's so strange to me how not using a framework is so often displayed as the "simple" solution. Not using a framework basically means using global, mutable state. This is maybe ok if all you need is one or two dropdowns. But anything further it isnt the way.
dtagames 4y ago
Few of the comments seem to focus on Lit, the "anti-framework," which is a very valid alternative. In Lit, there are *no* pre-built components. No boxes or buttons or controls or routing. None. You make what you need. Sounds daunting but, as the author points out, it frees you from cruft. You make only what you need. YOU design the API and syntax. And you add/remove whatever you want, whenever. It would be hard for me to go back to canned components after Lit! Try the interactive tutorial: https://lit.dev/tutorial/ https://lit.dev/tutorial/
xtalx 4y ago
I think React is great. In Some instances of useEffect can seem inscrutable. I believe svelte is a great counter to a lot of the ceremony in React and I see it as the most compelling “framework” available. I sorta miss JSX with it but it’s not that important after a while. I find all the tech and rhetoric that comes from Google Dev Rel people (excluding a few gems) to be either pretty damn good but evangelized distastefully or just straight up incoherent. I find everything thing with web components and shadow dom and all that abhorrent. Yeah it’s the “platform” but the APIs are super complex, convoluted and filled with caveats all to not use a framework. I also believe the narrative that big JS bundles are ruining the web is a diversion. Google, and more specifically, monetization and advertising is ruining the web directly. Large JS bundles are secondary. Advertising and ad revenue ruined the web before the much aligned SPA.

334 points by tomduncalf 4y ago

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 4y ago
What is a reactive data source?
- bern4444 4y ago
  I imagine a webhook source could be a reactive data source or any stream based API
- sibit 4y ago
  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.
- mathgladiator 4y ago
  A data source that you subscribe to and get a stream of updates. I'm building https://www.adama-platform.com/ https://www.adama-platform.com/
- zelly 4y ago
  RxJS aka the reason so many websites take 100MB of memory nowadays Don't use it
  - nicoburns 4y ago
    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.
    - djrockstar1 4y ago
      I got into RxJS cause I had to deal with an Angular project a few months ago, what's wrong with it?
    - cnity 4y ago
      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/utils/atom.js https://github.com/curlywurlycraig/vdom-util/blob/master/src...
      - thoughtpalette 4y ago
        Link doesn't work for me. 404s
        cnity 4y ago
        Apologies, should be good now.

lozenge 4y ago

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 4y ago
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 4y ago
  React very much feels like its own platform to me - having its own browser tools to debug it is a dead giveaway.
  - v0idzer0 4y ago
    I think it feels that way because it’s a bit of a paradigm shift in terms of the way we think about building user interfaces, but the reality is its just javascript running in a browser. I’ve been writing react over 10 years and used to devtools just a handful of times. They’re by no means necessary. I used to use an extension for jQuery to quickly find css selectors. Nobody was saying we weren’t using the platform then. It’s just a strange form of posturing from web component enthusiasts who are frustrated they aren’t taking off. And these enthusiasts are 99% Google employees who work on web components.
    - LAC-Tech 4y ago

daok 4y ago

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 4y ago
> 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.

bobertlo 4y ago

My ad for web components: btw I used to use react

lcnPylGDnU4H9OF 4y ago
> 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.
- bobertlo 4y ago
  I was only joking that the title of the piece seemed slightly misleading/baiting! (but I also was not familiar with the term "using the platform")
deleted 4y ago
[deleted]

_pdp_ 4y ago

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.

youngtaff 4y ago
Jack builds Chrome DevTools, that's a really rich app and seems to work pretty well
otikik 4y ago
> 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 4y ago
  > 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 4y ago
  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.

ng12 4y ago

> 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.

nightski 4y ago
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 4y ago
  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

dmitriid 4y ago

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 4y ago
[deleted]
e111077 4y ago
> talks about lit-html which is a fully incompatible replacement for Polymer. lit-html is completely different from web components and not meant to replace Polymer. lit-html is a library that just handles rendering and lit-element, which is meant to replace polymer uses lit-html as its renderer to make web coponents.
- dmitriid 4y ago
  Semantics. If you go to Polymer website, it says this: "The Polymer library is in maintenance mode. For new development, we recommend Lit", and it links to what literally everyone I've seen calls lit-html (because that's how it started). React is also just a library that handles rendering. But sure, "it's different".

TAKEMYMONEY 4y ago

> 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/integrations/react 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 4y ago
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 4y ago
  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 4y ago
    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/ https://claytongulick.github.io/applicationstate/

andrewstuart 4y ago

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__ 4y ago

Aren't web components more of an addition to frameworks like Bootstrap than a React replacement?

Bellend 4y ago
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__ 4y ago
  But React does much much less than Angular.
  - Bellend 4y ago
    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.
zelly 4y ago
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.

deleted 4y ago

[deleted]

apprewired 4y ago

> 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.

timfsu 4y ago
Not OP, but if you're building a small scheduler for batching changes, it should be pretty straightforward: - `jobs` is an array of functions - enqueue adds a job to `jobs` and starts running jobs if not running - job running can be triggered by animation frames or setTimeout

interlocutor 4y ago

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 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.

tentacleuno 4y ago
> 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 :-)
kall 4y ago
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 4y ago
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.

LAC-Tech 4y ago

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 4y ago
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.
- xigoi 4y ago
  Reading the MDN documentation for parts, how are they different from classes?
  - claviska 4y ago
    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-parts/ https://www.abeautifulsite.net/posts/when-to-create-css-part...
wrnr 4y ago
I've come to the conclusion that web components (with or without shadow roots) are not the best "elementary particle" to build a webapp out of. Most of the time you want simple divs and sometimes you want custom-tag. The important thing is to have a setup where you can quickly promote a component into a web component proper. I think solid.js has a nice solution this, where you just call a function that wraps the component into a web compoent and registers a tag for it. One issue I have with lit is that it just forces you to turn everything into a web component instead of a carefully deliberated choice.

rglover 4y ago

Come on over rovers: https://github.com/cheatcode/joystick 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.

oorza 4y ago
Hard to say it's a good sell coming from React when the component API has been twice-replaced by better options in the React world. This looks awfully tedious to use.
- rglover 4y ago
  Tedious? It's as straightforward as you can get (by design). React has devolved into an utter mess of ambiguous patterns and unnecessary abstractions that make the work far more difficult than it needs to be.

rexpop 4y ago

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.

ummonk 4y ago

It’s bizarre to see the author waxing poetic about the small size of lit-html when it’s actually no smaller than Preact.

e111077 4y ago
FWIW preact is 4kb minzipped (+ 700 bytes for htm package templating) while lit-html is 3.3kb minzipped. Author also talks a lot about the issues with losing control of the component model when using preact

mappu 4y ago

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.

e111077 4y ago
Not sure if you're aware of it, or saying it's missing features, but lit-analyzer adds compile-time linting and type checking while lit-plugin provides IDE integration of the tool

zelly 4y ago

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.

semiquaver 4y ago
Every real world use of Web Components that I’ve seen uses <template> elements and/or imperative DOM methods to implement rerendering. These are blazing fast and exactly what React uses. It’s possible to build a slow app using Web Components, but that’s true of every library, including React.
- Izkata 4y ago
  Same here; I suspect they've mixed up defining the component (where some examples do use innerHTML) and using the component (which don't).
brundolf 4y ago
> 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). You are right (I think) that there's no good way around converting attributes to and from strings, though the performance overhead there should be minuscule in most cases. The bigger problems with that are a) some data (like functions) can't be serialized at all, and b) it leaves a lot of room for passing invalid values

kall 4y ago

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.

sebmellen 4y ago
Not only that, but so many strong engineering orgs build on React that I can't imagine it degrading very soon. Even if the top contributors left, Facebook imploded, and Airbnb disappeared, I'm quite certain there would be a crowdsourced effort to rescue and maintain the framework.
- qudat 4y ago
  There’s even preact which is similar to react but a different org.

jrochkind1 4y ago

I admit I don't really understand the web components/cusotm elements "story". (I'm not even totally sure the right terminology, or what OP is talking about specifically). Are these now useable on any contemporary browser? Or do you use some kind of polyfill? Anyone have a good from-zero tutorial for the approach OP is talking about?

semiquaver 4y ago
Yes, they are usable without polyfills in any modern browser. The general idea is that you can register new element types whose behavior is defined in JavaScript classes. They interact with the rest of the DOM in the same way other HTML elements do: by emitting and handling events. They can also maintain a “shadow DOM” with its own HTML subtree and CSS scope, so that you can make complex elements whose internal state is encapsulated from the rest of the DOM.
- protocontrol 4y ago
  Hi. Sorry I couldn't parse that without a specific example. In which typical use cases should I create new element types?
  - cube00 4y ago
    Whenever you'd usually create a new component in React.
  - mhoad 4y ago
    This might be a good introduction from the Lit team themselves to see what this looks like in practice https://youtu.be/QBa1_QQnRcs https://youtu.be/QBa1_QQnRcs

deleted 4y ago

[deleted]

FpUser 4y ago

I use plain JS, couple of libs and web components for business front ends. Works like a charm. Never needed React. It was created by FB to solve FB problems. Being small company this React approach to me it is just plain overhead.

didip 4y ago

Whenever I see a few internal apps made with React/Vue, they would miss super basic features such as highlight-able text or canonical permalinks. It got me thinking, why these frameworks make simple things difficult? Note that I am a backend/infra engineer (but I am able to build complex web app using jQuery back in the old days.) so I may be missing something here.

darepublic 4y ago

I have known about web components for some time but this article and the linked mdn guide have whet my appetite to maybe give it a try. Perhaps for my next bespoke small web app I can try my hand at web components rendered server side.

wrongandrew 4y ago

Both React and Lit's approach (that requires schedulers and user uncontrolled updates) are completely unnecessary for most if not all of the applications currently using React and I bet nobody even knows why they exist. Facebook made React like this because of these requirements: they wanted their chat application that requires various real time small updates to multiple parts of the page to run quickly where a wipe and rerender approach is too slow, while being declarative because their constantly rotating staff had trouble writing it imperatively. To meet this requirement you need: a constantly revolving staff that are of varying degrees of competence and can't write non-buggy imperative code in the few situations you can't just wipe and re-render a situation in your application where wipe and re-render is too slow, AND the situation is too complex to hand-write the individual updates manually The other decision React made that was wrong was the need for JSX. They decided on JSX because they made a mistake many people make when just using the pure JavaScript API for creating components - they tried to make it nested like html using a fluent/chained call approach. As it turns out, trying to keep the nested HTML structure is not necessary for readability. My library is github.com/thebinarysearchtree/artwork After using it, it makes React look like SOAP vs JSON. It has less code, runs as fast as you can get, and everything is in your control because it is just web components with some functions to handle the repetitive parts.

djbusby 4y ago
Would love to see some comparison between yours and React, Svelte, Riot, Angular and Vue (or others)
- deepstack 4y ago
  For comparison, just read this: https://mithril.js.org/framework-comparison.html https://mithril.js.org/framework-comparison.html Personally I prefer mithril or Soild over all other front-end framework. They light and fast. And Mithril author had in depth knowelge of the other frameworks.
mattwad 4y ago
This actually looks really nice

bfz 4y ago

Article makes a variety of already well understood points, but only briefly touches on the most interesting one (from my perspective): durability. If the thing you're integrating is an evolving, improving moving target, and it's coming out of a team of only a handful of people, double any visible costs associated with your application for the sucker who must build it in 2 years time to add some new feature. It is possible to build a strong and easy to communicate case for avoiding frameworks using long term maintenance costs as the basis. jQuery was actually pretty good at this, it only had one big flag day that I can remember. In that sense, jQuery was much closer to what you get for free working directly against the platform interfaces. Deprecation cycles are much, much longer, and burden of proof much higher for new features in the browser than pretty much any third party framework. Somewhere here on the thread there was slander directed at Closure Library / Compiler. In this context, that is so totally tone-deaf, Closure Compiler/Library projects from 2010 still build with little to no changes today (based on local experience). I can't say the same for any alternative I have used in the past decade.

dmitriid 4y ago
> but only briefly touches on the most interesting one (from my perspective): durability React is over 10 years old and is backwards compatible probably all the way back to its 0.x versions. Web Components have already deprecated and removed v0 of Custom Elements, and deprecated HTML Imports. On framework/library side: Polymer 1 wasn't compatible with Polymer 2 IIRC, and then Polymer was scrapped and discontinued in favor of lit. React is a surprisingly safe bet for durability.

jwmoz 4y ago

Server side rendering ftw

jpkeisala 4y ago
I have been waiting Server Side rendering to come back. I can't get my head around why build a normal brochure website using frontend frameworks.

stanislavb 4y ago

Same here. I've been slowly getting rid of old React components on both SaaSHub & LibHunt. It's much easier to go forward and maintain your code when there's less JS complexity. For the curious ones - these are both Ruby on Rails based projects.

robertlagrant 4y ago

I've really enjoyed using HTMX + Flask rendering HTML. It seems very ergonomic.

likortera 4y ago

This reminds me of those posts like "Flask is better than Django". Sure, if you want to reinvent 90% of what's given to you for free with the bigger framework.

rochak 4y ago

I wish I didn’t say this but I just hate using React now. What was once simple is becoming more and more complex and I wish I had just stuck to a more batteries included framework like Angular/Vue/Svelte but the time has passed now. I’m just glad I don’t have to work on Frontend anymore.

k3liutZu 4y ago
I mean it seems you don't really like Frontend — not specifically React

ge96 4y ago

Few things that annoy me about react are mostly minor personal missed details like stale state in websockets, sometimes asynchronous state updates/wrong order; things you expect to work in a certain way but don't. Then it's like "you should use a [use]Reducer for that". Generally I like react/my go to. Just sometimes it does things not intuitive to me.

fbn79 4y ago

In my projects I use cycle.js/snabbdom and I'm already following many suggestion of the article (es. form data). My next goal would be to discard snabbdom (and virtualdom) and use custom elements. For that I'm evaluating a library like https://github.com/WebReflection/uhtml https://github.com/WebReflection/uhtml and all it's ecosystem of utility

baxuz 4y ago

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.

WA 4y ago
So what do you do? Hand-craft Web Components?
- dtagames 4y ago
  In Lit, yes. It's hand-crafted web components with support for one-way data binding by parameter passing. Any other updates are by event notifications, as the commenter said.
  - WA 4y ago
    Ah thanks for clarifying, it sounded like you wouldn't recommend either Lit or Stencil.
    - dtagames 4y ago
      Sorry if I wasn't clear. I'm a huge fan of Lit! It gives you the freedom to make your own framework -- the parts you need. I respect the OP's comment and our difference of opinion, which is why I didn't reply negatively to it.
- baxuz 4y ago
  I avoid using them, except when having to expose a component to a third party, if they _really_ want the ergonomics of using WCs. Then I'd use something like https://github.com/preactjs/preact-custom-element https://github.com/preactjs/preact-custom-element, https://stenciljs.com/docs/custom-elements https://stenciljs.com/docs/custom-elements or https://github.com/solidjs/solid/tree/main/packages/solid-element#readme https://github.com/solidjs/solid/tree/main/packages/solid-el.... As far as I see, there is nothing that WCs provide which isn't already solved, in a better way, both for devs and users. And making a framework that use custom elements and shadow DOM for component-based logic and encapsulation seems like a purely philosophical approach to adhere to some vision of "platform purity".

iveqy 4y ago

All comments is about developer experience. What about user experience? I find many framework adding a lot of data, loading times, etc. for little gain for the user.

KaoruAoiShiho 4y ago

Why lit-html over something like pug?

lysecret 4y ago

It's so strange to me how not using a framework is so often displayed as the "simple" solution. Not using a framework basically means using global, mutable state. This is maybe ok if all you need is one or two dropdowns. But anything further it isnt the way.

dtagames 4y ago

Few of the comments seem to focus on Lit, the "anti-framework," which is a very valid alternative. In Lit, there are *no* pre-built components. No boxes or buttons or controls or routing. None. You make what you need. Sounds daunting but, as the author points out, it frees you from cruft. You make only what you need. YOU design the API and syntax. And you add/remove whatever you want, whenever. It would be hard for me to go back to canned components after Lit! Try the interactive tutorial: https://lit.dev/tutorial/ https://lit.dev/tutorial/

xtalx 4y ago

I think React is great. In Some instances of useEffect can seem inscrutable. I believe svelte is a great counter to a lot of the ceremony in React and I see it as the most compelling “framework” available. I sorta miss JSX with it but it’s not that important after a while. I find all the tech and rhetoric that comes from Google Dev Rel people (excluding a few gems) to be either pretty damn good but evangelized distastefully or just straight up incoherent. I find everything thing with web components and shadow dom and all that abhorrent. Yeah it’s the “platform” but the APIs are super complex, convoluted and filled with caveats all to not use a framework. I also believe the narrative that big JS bundles are ruining the web is a diversion. Google, and more specifically, monetization and advertising is ruining the web directly. Large JS bundles are secondary. Advertising and ad revenue ruined the web before the much aligned SPA.