[HN Gopher] Web Components Eliminate JavaScript Framework Lock-In
___________________________________________________________________
Web Components Eliminate JavaScript Framework Lock-In
Author : jakelazaroff
Score : 223 points
Date : 2023-11-27 16:41 UTC (6 hours ago)
(HTM) web link (jakelazaroff.com)
(TXT) w3m dump (jakelazaroff.com)
| yohannparis wrote:
| Thank you for the great read! The last few weeks have seen a lot
| of thought on HTML web components, and I'm really happy about it.
| shadowgovt wrote:
| My hair always bristles a bit when I see plans to "eliminate
| JavaScript Framework Lock-in."
|
| For a backend service, it doesn't matter if you use no framework
| or one or five, other than pain for your developers having to
| learn the complexity; storage is so cheap it's nearly free,
| executable RAM slightly less so, and the end-user doesn't care
| how complex your server is.
|
| Frontend code gets pushed over a wire to your end-user. If you're
| using three overlapping frameworks to build one web service
| frontend purely because someone in your team likes Svelte and
| someone else likes React... _that 's a problem._ You'll be
| pushing more bytes than you should to your end-users, and that
| cost doesn't scale the right way; in fact, the more popular your
| app, the more redundant bytes you'll be passing.
|
| We don't want to enable multiple frameworks in the UI. We should
| be settling on one and committing everyone on the frontend team
| to using it (ideally lock-stepped to the same version of it)
| within each app-shaped thing we create as a frontend team.
| jakelazaroff wrote:
| Author here -- I feel like I addressed this point in the
| article, no? Obviously using a zillion frameworks in your app
| is a bad idea, but there are a bunch of actual reasons that
| encapsulating and/or mixing frameworks might be useful:
|
| - Gradually migrating from one framework to another
|
| - Including interactive "islands" within a static or server-
| side rendered page
|
| - Using a dependency only available in one framework from
| within another (this works best if the dependency framework has
| a small footprint -- e.g. using Svelte within React is better
| than vice versa)
| politelemon wrote:
| It isn't a standard HN post if it isn't claiming
| $new_technology will eliminate $old_technology.
| willsmith72 wrote:
| i did this back in 2019 to make the transition smoother between
| angular.js and react
|
| > there are ways to build a web app other than writing the entire
| thing with a single JavaScript framework
|
| totally agree, and reducing rewrites or making converting them
| into "strangler" rewrites is a huge win
|
| on the other hand, it reminds me of the microservices hype a few
| years back. Just because you can, doesn't mean you should.
| Uniform languages, frameworks, coded patterns make things SO much
| smoother for an organisation.
|
| I would repeat the author's words of warning: "you should not
| build a real app like this!". you should seriously think hard
| before adding this level of complexity to any production app
| xutopia wrote:
| I've seen the entire industry move towards React/Angular type
| frameworks and it's invariably been a really bad thing. Large
| projects end up with front end specialists and backend
| specialists and very few actual full stack devs. What ends up
| happening is that no one person can do an entire feature anymore.
|
| I'm all for web components!
| lopis wrote:
| This is not my experience at all. Why can't a full stack dev
| know react or angular?
| schwartzworld wrote:
| Apparently because learning anything more than the minimum
| necessary to put pixels on a page makes you a specialist?
| codegeek wrote:
| GP didnt say that. They said lot of devs become "front end"
| or "back end" specialists which means that they cannot do
| full stack. Full stack devs knowing React is fine. The
| problem is that most "React devs" don't know full stack and
| most "backend devs" don't know full stack.
| shadowgovt wrote:
| The concerns, constraints, and behavior of server-side headless
| software and a viewer that fetches and renders data from a
| remote backing store are entirely different.
|
| Is it a bad thing that organizations specialize on those
| concerns? Seems like the most obvious place to slice
| responsibility, even if it means every feature is split across
| two teams. After all, the performance of the backing store is
| impacted not by neigbhoring logic in the UI infrastructure but
| by neighboring state in the backing store; it should be
| _someone 's_ job to be looking at the backing infrastructure
| holistically and not sliced as "frontend-backend feature A,
| frontend-backend feature B, etc."
| dbingham wrote:
| One of the linked articles [1] makes an interesting claim that
| feels like a reach to me, but I'd be interested in hearing HN's
| take on it:
|
| > At this point React is legacy technology, like Angular. Lots of
| people are still using it, but nobody can quite remember why. The
| decision-makers in organisations who chose to build everything
| with React have long since left. People starting new projects who
| still decide to build on React are doing it largely out of habit.
|
| I'm going to withhold my own thoughts about that quote, cause I'm
| curious what everyone else thinks.
|
| Wrt. Web Components, I played around with Web Components about
| half a decade ago and they felt promising but not ready for prime
| time yet. They were pretty messy and felt like they did a poor
| job of encapsulation. (At least at the time.) I haven't looked at
| them recently, but the code examples in these articles look much
| better (and cleaner) than what I remember.
|
| [1] https://adactio.com/journal/20618
| troupo wrote:
| > They were pretty messy and felt like they did a poor job of
| encapsulation, ultimately. (At least at the time.)
|
| They are still messy. https://w3c.github.io/webcomponents-
| cg/2022.html
| wayfinder wrote:
| As someone who does remember why because they've been building
| sites since the 90s, it's because the React team created a
| preprocessor (JSX) to let you embed HTML tags in JavaScript.
| This fixed the problem that other languages like Java, Python,
| etc. don't have because those languages has assemblies/packages
| so they can put HTML templates in separate files and load them
| in your app. There is zero standard way to do that in JS and
| every custom way you invent looks like trash.
|
| Doing something like this.shadow.innerHTML = `your HTML` with
| web components is terrible. document.createElement() is
| terrible. $('div').appendChild() is terrible. <script
| language="html" name="my-template"><!-- --></script> is
| terrible. HTML(Div(Strong(text))) is terrible*. Storing
| templates as JSON and writing a one-off loader is terrible.
| <div style="display:none">template</div> is terrible. I've done
| it every possible way and they are all terrible.
|
| JSX fixed all that.
|
| The biggest previous attempt at something like JSX was E4X
| where you could embed XML straight into JS, which was kinda
| nice except it added the entirety of XML and its complexity. I
| creamed when it came out but then I tried it and it was not it.
| (E4X ended up surviving a little longer in Adobe Flash though.)
|
| E4X: https://en.wikipedia.org/wiki/ECMAScript_for_XML
|
| *This is what JSX compiles to behind the scenes.
| breadwinner wrote:
| What if you could have the best of both worlds? What if you
| could use JSX templates and use standards-based web
| components? You can.
|
| Here's an example of using a web component in a JSX template
| (look for zx-listeditor): https://github.com/wisercoder/uibui
| lder/blob/master/WebCompo...
|
| Here's how the web component is implemented, also using JSX:
| https://github.com/wisercoder/uibuilder/blob/master/WebCompo.
| ..
| wayfinder wrote:
| Not saying that you can't. I'm just explaining why React
| won and how it was blatantly obvious that it was going to
| win when it came out (that is, if you were there in the
| before-times).
| breadwinner wrote:
| Agree with you on that. React was a breath of fresh air
| compared to what we had in the before-times, such as
| Angular, Ember and so on. The canonical demo of Ember.js
| was two-way data binding. React did away with two-way
| data binding and introduced JSX syntax. This was a major
| step forward. Code suddenly looked sane and readable.
| Then they took two steps backward when they introduced
| hooks. Code went back to being unreadable.
| chatmasta wrote:
| Also, the entire OP article is demonstrating this... I'm
| not sure many of the comments here actually read it...
| zelphirkalt wrote:
| Interesting. Yet I find that React HTML--that is not actually
| HTML, but a look-alike, a dialect if you want--to be exactly
| what I dislike about React. That is because it still
| encourages people to put JS in their HTML in their JS in
| their ... And we are almost back to crazy PHP land of "I
| treat HTML as a string and blend everything together into one
| big lump.", instead of using a templating engine, that treats
| HTML in separate files, or making use of a DSL, that treats
| HTML as structured data, say for example SXML. Also there are
| issues with that custom HTML-look-alike preprocessor, because
| you cannot write class="...", because then somehow it gets
| syntactically confused, because "class" is now a keyword in
| JS.
|
| This all feels rather half-baked. Why can't the
| parser/prprocessor distinguish between that "class" and
| "class" in JS source code? We can have reusable HTML snippets
| (some may call components) with normal templating engines
| easily. Look at something like Jinja2 and how to reuse blocks
| and macros. Yes, some React component can encapsulate its own
| interactive behavior. That is only because we are already
| writing JS though, so we can already write frontend logic.
| But do we actually want that? Coupling state and behavior? I
| think we might not. Writing a script that gets served only on
| those rendered templates, where it is needed is not so hard
| either, when using a normal templating engine.
| wayfinder wrote:
| Your criticism was the biggest one of React when it came
| out -- mixing view code with your controller code. Big no
| no. Everyone loved the MVC pattern (model-viewer-controller
| where you separate these things in different places) and
| what React did was a big no no.
|
| But you know, if you are trying to put HTML templates in
| separate files, you have to now send extra HTTP requests.
| That's an _even bigger_ no no.
|
| In other languages, you can just put your template in a
| separate file and load it from your package/.jar/assembly.
| Super easy and most importantly, 100% standard and provided
| by the environment.
|
| So people just settled with React because it worked and no
| successfully invented a standard bundle format for the web.
|
| F' it we said.
| nostrademons wrote:
| > But you know, if you are trying to put HTML templates
| in separate files, you have to now send extra HTTP
| requests. That's an even bigger no no.
|
| It's not actually, with HTTP/2. The separate requests are
| all multiplexed over the same connection, often with
| prefetching, and compressed together so that there's
| little to no overhead vs. putting them in the same file.
|
| This illustrates a common failure point for web
| frameworks though. They encode a lot of folk knowledge
| about how the web works, but _that folk knowledge becomes
| obsolete as browsers change_.
|
| Another prominent React example fits into this category:
| the virtual DOM. React assumed that DOM manipulations
| were slow and Javascript manipulations were fast, and so
| they built up an internal representation of the DOM in
| Javascript so they could manipulate _that_ one and diff
| the change to apply it to the real DOM. This was true
| from approximately 2008 (when V8 introduced JS JITting)
| to 2013 (when Blink /Webkit/Firefox all moved to a dirty-
| bit system for DOM manipulations), which not
| coincidentally is when React was designed. But since
| then, DOM manipulation has been just pointer swaps and a
| dirty bit flip, and _if you 're careful not to invoke any
| operation that triggers a reflow and repaint_ you can
| make your modifications directly in the DOM for roughly
| the same cost as making them in JS. Since React is
| declarative it could easily have enforced the no-reflow
| rules without the virtual DOM, but because DOM
| manipulations were expensive when its designers learned
| web programming, it introduces an unnecessary concept.
| chatmasta wrote:
| Multiplexing requests doesn't help when there is a
| logical dependency between them, e.g. some javascript
| code needs to download _and then execute_ just to
| determine what template files it needs to subsequently
| download. That can 't be parallelized.
| nostrademons wrote:
| If you're in a position where you could've written the
| template inline in your source file, this is a _static_
| dependency, independent of any page content, and can be
| handled through build systems and prefetching.
| QuadmasterXLII wrote:
| Can I borrow some knowledge? What sort of operations
| trigger a reflow and repaint?
| nostrademons wrote:
| Short answer: anything that _modifies_ the DOM, followed
| by a call which _measures_ geometric properties of the
| DOM. Also you get an automatic reflow /repaint when
| control leaves the Javascript event handler that triggers
| a modification (this is how the browser's UI is updated).
| You can batch up a bunch of modifications without
| triggering a reflow and then have it account for all of
| them on next reflow, though, which is what React tries to
| achieve with the Virtual DOM and what you get for free
| after ~2013.
|
| Slightly longer answers:
|
| [modifies] https://developers.google.com/speed/docs/insig
| hts/browser-re...
|
| [measures]
| https://gist.github.com/paulirish/5d52fb081b3570c81e3a
|
| Also there's a bunch of exceptions where you can modify
| things without triggering a full reflow. Anything that
| takes elements out of normal flow (position: fixed,
| position: absolute, float:, overflow: hidden) creates a
| layout boundary where changes inside only reflow the
| containing element. Any element with a transform: or
| opacity: property gets rendered as a 2D texture on the
| GPU, and then you can do subsequent transform/opacity
| animations purely on the GPU without touching the CPU.
| Used to do this to make performant animations on mobile
| devices.
| lioeters wrote:
| "Generally, all APIs that synchronously provide layout
| metrics will trigger forced reflow / layout."
|
| > What forces layout/reflow. The comprehensive list.
|
| > All of the below properties or methods, when
| requested/called in JavaScript, will trigger the browser
| to synchronously calculate the style and layout*. This is
| also called reflow or layout thrashing, and is common
| performance bottleneck.
|
| https://gist.github.com/paulirish/5d52fb081b3570c81e3a
| wayfinder wrote:
| Oh I'm aware, but I'm talking historically.
|
| But HTTP/2 is not the right example. You're missing some
| things on the web timeline.
|
| Long before HTTP/2 (time in web terms), and after React
| (and Angular, etc.) came about, people created actually-
| popular bundler toolchains that can bundle arbitrary
| files together and then incrementally load them as
| needed. This effectively fixed the multiple HTTP request
| problem long before HTTP/2 existed. Efficient template
| files have been possible for years. (Granted, not
| anything standard though.)
|
| The issue right now is that someone has to make a full
| toolchain with strong developer support to make this a
| de-facto and popular way to distribute apps. Just because
| you have a bundler or HTTP/2 doesn't mean you have a nice
| way to make use of it. You need a nice library. Your
| usage examples need to look pretty. It needs to work with
| other toolchains. It needs to look like your library will
| be supported for a long time, just like how React was
| supported by Facebook.
|
| You can't just write a blog post about how it's possible
| because you're basically asking your readers to invent
| and maintain a library or worse, roll their own internal
| library that will confound people at their company.
| throwaway_1987 wrote:
| >But you know, if you are trying to put HTML templates in
| separate files, you have to now send extra HTTP requests.
|
| Most projects that I have been involved with have some
| kind of build system that does all sort of magic. It
| should be possible to include the template in the JS file
| during the build process
| nicoburns wrote:
| Yep, and that's what was being done before React existed.
| JSX took over because people (including me) prefer to
| have the full power of JavaScript for their templates
| rather than a half-based templating language.
| nightski wrote:
| Except it's not half baked. Because guess what - now you
| need a new template language that supports constructs like
| conditionals, loops, etc... You basically end up
| implementing a half-baked version of javascript with an
| unfamiliar syntax. Even worse they need to interact with
| state. Many template engines introduce some sort of "data
| binding" abomination which is a complex way of saying how
| you want the state to interact with the view.
|
| React is simple. Here is your data, and here is a function
| that transforms that data into a view.
|
| Templates are terrible, and that is a hill I am willing to
| die on.
| tubthumper8 wrote:
| > Also there are issues with that custom HTML-look-alike
| preprocessor, because you cannot write class="...", because
| then somehow it gets syntactically confused, because
| "class" is now a keyword in JS.
|
| > This all feels rather half-baked. Why can't the
| parser/prprocessor distinguish between that "class" and
| "class" in JS source code?
|
| Remember that React is "just JavaScript", JSX is a syntax
| transformation of JavaScript. When you use `className` in
| your JSX, you're using the standard DOM Attribute [1]. You
| wouldn't use `class` either in vanilla JS to set the CSS
| class, you'd use `className`.
|
| https://developer.mozilla.org/en-
| US/docs/Web/API/Element/cla...
| nostrademons wrote:
| I liked the templates-as-JSON approach much more than JSX.
| HTML is terribly verbose, doesn't fit well with the rest of
| Javascript, doesn't let you use JS language features like
| destructuring or iteration on the component tree, and doesn't
| let you factor out common properties into their own data
| structure. Would much rather see: { tag:
| 'div', padding: '2px', position: 'absolute', content:
| [myText] }
|
| than <div style="padding: 2px; position:
| 'absolute'">${myText}</div>
|
| The main reason I ended up settling for JSX was just
| convention: I don't want to be the one with my own unique
| format for UI trees unless I can convince everybody else to
| use my format.
|
| Note that Jetpack Compose has a very similar declarative
| reactive paradigm as React, but represents components with
| Kotlin language mechanisms. IMHO I like it much better,
| because it's much more _composeable_.
| marcosdumay wrote:
| > <div style="display:none">template</div>
|
| It's new and has no significance for the history. But I think
| it's relevant to point out that <template
| id="myhtml"><div></div></template> isn't horrible.
|
| And that those articles about web components are doing a
| really bad job of using constant strings instead of
| this.shaddow.innerHTML = getElementById("myhtml").innerHTML.
| vitaflo wrote:
| 100% agree. Like you I've been building sites since the mid
| 90s and always was pulling my hair out at all the convoluted
| ways we would attempt to handle HTML in these JS frameworks.
| As someone who knows HTML and CSS and vanilla JS, as soon as
| I saw React all I could think of when I saw JSX was
| "finally!".
|
| Yeah it's another framework with its own quirks but it lets
| me think about the UI in the same way I've thought about it
| for 25 years. For someone like me that's a godsend.
| xtracto wrote:
| I remember using PHP and CodeIgniter in the mid-2000s. IIRC
| PHP had that template-interpolation thing solved since the
| first day: You populated your Views with PHP code.
| WorldMaker wrote:
| > HTML(Div(Strong(text))) is terrible*
|
| > This is what JSX compiles to behind the scenes.
|
| Oh, it is much worse than that. By classic default it is:
| React.createElement('div', { /* props and attributes ... */
| }, React.createElement('strong', { /* ... */ },
| text))
|
| Recent updates and other JSX frameworks simplified the name
| of `React.createElement` to just `jsx` or `h`. I've seen
| projects that manually write `h` calls like that everywhere,
| and it is indeed terrible.
|
| (Source: I've just completed a bunch of crazy TSX work and
| got pretty familiar with the compiled forms.)
| gustavus wrote:
| It sounds like the common thing that someone in the Frontend
| space would say, that a technology less than 5 years old says
| the technology is old.
|
| I prefer the terms stable, mature, or hardened.
|
| People use React/Angular because large products are forced to
| have a way to organize things across multiple developers and
| time. Now don't get me wrong I think these JS bloated websites
| are an abomination that have largely made the web worse and not
| better, especially since UX "engineers" feel a compulsive need
| to change the layout every 6 months and now even simply
| scrolling through a page involves 50 web requests, and takes a
| full 3 minutes to load the next page... but I digress.
| tshaddox wrote:
| Fascinating that React simultaneously receives criticism as
| being
|
| 1) boring, old technology that has been around for so long that
| no one even remember why it was chosen in the first place, and
|
| 2) extremely fast-churning, bleeding edge software that is
| constantly changing and breaking because the JS community is
| more interested in chasing trends than building robust stuff.
| pwdisswordfishc wrote:
| React has merely aged, not matured.
| paulddraper wrote:
| Same people who say:
|
| 1) the ecosystem keeps chasing shiny tech that is constantly
| changing, not boring solutions
|
| 2) everything should be written in Rust
| robin_reala wrote:
| React "won" because Facebook spent three years flying devrel to
| every web conference on earth to persuade other people that
| Facebook's problem space was applicable to small agencies.
|
| Back in reality, React is slow and massively overbuilt for the
| majority of stuff that most people are building.
|
| If you played around with Web Components a long time ago then
| you probably played with the v0 spec, which was somewhat
| different to the current version.
| troupo wrote:
| > React "won" because Facebook spent three years flying
| devrel to every web conference
|
| You do know that Google _sponsored_ and ran things like
| Polymer conf? That it builds lit? That Google 's devs have
| literally overrun and overruled most web specs committees?
| That Google has spend hundreds of millions of dollars
| promoting Web Components?
|
| And yet here we are.
| robin_reala wrote:
| Polymer was incredibly even slower that React and even more
| overbuilt, and it had the added negative that it tried to
| enforce a visual style as well, which was too much for most
| people. Google couldn't spend its way out of that hole.
|
| As for Web Component specs, we got v1 because of Apple and
| Mozilla: Google would happily have stayed with v0.
| pseudosavant wrote:
| I'm glad to have read this today. I'm going to look into
| how I could use web components in my next side project. I'd
| really like something that worked easily with SSR and
| client-side, maybe using htmx.
|
| In retrospect, I think I avoided web components because of
| Google and their aggressive dev relations pushing Polymer.
| It felt so one-sided that it didn't seem like a web
| standard. It felt more like a Google "standard" like NaCL.
| Having to ship Polymer to support non-Google browsers felt
| even more heavy weight than React.
| troupo wrote:
| > I'd really like something that worked easily with SSR
| and client-side
|
| Then you should skip Web Components :)
| robin_reala wrote:
| For sure. SSR is one thing that React has done well, and
| that Web Components don't have a great story for.
| pseudosavant wrote:
| I'm pretty sure that just shipping the HTML works. The
| nice thing if I use web components is that I can just
| have my backend create HTML that uses those components. I
| can create elements whatever way I want on the backend or
| the front-end so long as it is HTML.
| robin_reala wrote:
| Yes, if you stick to custom elements. If you want shadow
| dom encapsulation then you'll need to wait for
| declarative shadow dom to turn up in all browsers.
| JamesSwift wrote:
| React "won" I think because it trojan horsed itself as being
| "just the view" but then morphed into a hand-rolled kitchen-
| sink solution, and inertia kept people around.
| jeremycarter wrote:
| Accurate quote. Source: I was there.
| paulddraper wrote:
| !!!
|
| If React won, it was precisely because it was not
| "overbuilt."
|
| It was simpler (deliberately) than Backbone, Angular, Vue,
| Svelte, etc.
|
| You can implement a React clone in a few hundred lines, a la
| Preact.
| levitate wrote:
| I would not say that React won over svelte because of
| simplicity. Hate what you will about implicit behaviors in
| svelte, but the syntax is simple and intuitive.
|
| React won by being early and different. Svelte came out
| three years after React and got (unfortunately)
| steamrolled.
| paulddraper wrote:
| There two notions of "simplicity."
|
| One is that the implementation is very
| simple/transparent, e.g. C.
|
| The second is that it allows users to have very simple
| code, e.g. Python.
|
| React is mostly the first with a bit of the second.
| Svelte is the reverse.
| menssen wrote:
| "Lots of people are still using it, but nobody can quite
| remember why."
|
| I can remember why. This, and every other article I've ever
| read arguing to replace React with Web Components, completely
| misunderstands the point of React. It isn't about JSX. It isn't
| about encapsulation. It isn't about reusability.
|
| It is about enabling a design pattern where *the user interface
| is a pure functional transformation of the application state.*
|
| I kind of feel like people get tripped up by the fact that
| "virtual DOM" and "shadow DOM" sort of sound similar. They have
| literally nothing to do with each other. The React "virtual
| DOM" allows you to *completely re-output the entire user
| interface* on every state change, which is not possible with
| any other design pattern, and is not possible without a
| framework, because actually re-rendering the entire tree on
| every state change isn't performative (or usable).
|
| Anybody who is advocating an alternative to React needs to do
| one of two things:
|
| (A) Make a convincing argument that a _different_ design
| pattern is better. Some things we 've tried, which most people
| think are worse:
|
| 1. Using the DOM as your data model (jQuery)
|
| 2. Manually writing virtual representations of every view
| (Backbone)
|
| 3. Auto-magically two-way binding some data structure with the
| DOM (Angular 1)
|
| 4. Observables (Ember, maybe Angular 2+?)
|
| (B) Advocate a framework other than React that uses the same
| pattern as React, but improves the usability. I think the two
| places there is the _most_ room for improvements are:
|
| 1. Animations
|
| 2. useEffect() in general
|
| I have not seen anybody successfully do either A or B.
|
| Recommended reading: https://acko.net/blog/get-in-zoomer-we-re-
| saving-react/
| breadwinner wrote:
| > _It is about enabling a design pattern where the user
| interface is a pure functional transformation of the
| application state._
|
| This is only true for read-only components.
|
| There is no "pure functional" when you introduce state and
| interactivity. See here: https://mckoder.medium.com/why-
| react-is-not-functional-b1ed1...
| menssen wrote:
| It is _possible_ with React to write an application where
| components have no internal state, every component is
| "read only," and all UI changes are state transitions in
| (something like) a redux store.
|
| This is rarely done, because there are pragmatic reasons
| (e.g., animations) not to, but it is possible.
|
| The other mistake alternatives make is to try to make
| components having internal state "easier." It should not be
| easier! Every single useX() is a statement that "I am
| violating the proper design pattern of this application,"
| and it's a feature not a bug of React that you have to be
| obvious and intentional about it.
| dexwiz wrote:
| If one of the most popular APIs is a violation, then
| maybe the pattern is broken.
| DougBTX wrote:
| It's a misremembering of history. The point of all the
| "pure functional" discussion was that rendering the UI
| now shouldn't depend on how the UI was rendered earlier.
| The idea was to move away from the "create then update"
| paradigm to just "render". React would be responsible for
| which elements need to be created and which can be
| updated in place.
|
| To achieve that, it doesn't matter whether the state is
| local to a component or global across the application.
| breadwinner wrote:
| > _React would be responsible for which elements need to
| be created and which can be updated in place._
|
| That works for simple, read-only components. The moment
| the component starts managing its own interactivity you
| end up needing state, and at that point things break
| down. If you need to change props, you have to
| essentially recreate the component by changing key [1],
| and at that point, what is the benefit of React?
|
| [1] https://legacy.reactjs.org/blog/2018/06/07/you-
| probably-dont...
| gherkinnn wrote:
| I agree.
|
| useEffect should have been named
| useDangerousSideEffectAndThisIsNotALifecycleHook and the
| js influencers should have never compared useEffect to
| component lifecycles and the React team should have
| updated their docs and not wait 4.5 years to do so and
| the dependency array should absolutely not be optional.
| marcosdumay wrote:
| The idea of a reactive framework is that every interface
| component is either an event creator with no representation
| and that can update your application state, or an state
| viewer that has no inputs but can represent your state.
|
| It's decoupling those two that brings all the power.
|
| But the idea doesn't represent at all the web. So react is
| a mess of complex code trying to make the things you can
| create on the web behave like stateless pure components.
| Yet, it mostly works, and the react does indeed implement
| the idea that the interface is a pure functional
| transformation of the application state. (But I do disagree
| on claiming this the "entire idea", it's half of it at
| most.)
| tyingq wrote:
| Fair, though you can find plenty of stuff on the internet
| using React, but where the app/page itself performs
| abysmally. Meaning maybe there is some merit in approaches
| that are easier for lesser skilled teams to deliver in.
| menssen wrote:
| There is always space for options for "fast and easy" vs
| "robust and maintainable."
|
| Nothing will _ever_ beat the following as tech demo for how
| easy it is to make interactive UIs, but anybody who ever
| tried to reason through a large Angular 1 application would
| seriously hesitate to want to use it for something much
| more complicated.
|
| <script src="angular.js" /> <input ng-model="inputValue">
| <div>{{ inputValue }}</div>
| breadwinner wrote:
| > _Make a convincing argument that a different design pattern
| is better._
|
| Simple Model-View-Controller pattern works well for
| JavaScript, just as it does for ASP.NET Core, JSP and JSF,
| Ruby on Rails, Django and so on.
|
| Want proof? Browse this code:
|
| https://github.com/wisercoder/eureka/tree/master/webapp/Clie.
| ..
|
| This is the application: https://github.com/wisercoder/eureka
| jitl wrote:
| The server side style of MVC you describe is a far stretch
| from how MVC is practiced in retained-mode UI frameworks
| like UIKit, Cocoa, or Backbone. It's possible to make this
| style work fine with careful design and planning; Apple
| built web versions of Pages and Keynote using SproutCore
| (which evolved into Ember?) in 2013-era.
|
| In fact back then, everyone's big app was MVC - usually
| Backbone. I worked on Airbnb's host-side web app called
| "Manage Listing", it had probably 30+ models, 150+ views,
| 100+ controllers in Backbone. There were many bugs in this
| scale of app around making sure the DOM reflected the
| latest change to some model. the engineering team regarded
| the more complicated screens as a nightmare to maintain in
| our fast paced environment with many teams touching the
| code.
|
| Engineers at Airbnb started to adopt React as a solution to
| the problems we all experienced with MVC - not because it
| was a "hot new thing". When React came out, it was widely
| regarded as weird - it was more like "eww, this smells of
| PHP and needs a weird compiler, but pure function of state
| is a lot better than fiddling DOM manually...". Eventually
| we replaced Manage Listing backbone views with React
| components one by one until there was no backbone left.
|
| React is still kinda weird but it does solve this problem
| the best out of the modern frameworks. It's happy to over-
| render by default and prefers a correct DOM-for-state over
| everything else. It's clear thought that the mental models
| popularized by React are worth it - now Apple and Google
| are switching to the React model in their own frameworks.
| breadwinner wrote:
| MVC is a proven and popular technology. It works very
| well, otherwise it wouldn't be so popular. I notice you
| allude to "problems we all experienced with MVC" without
| mentioning _any_. Surely if there are so many problems,
| you would be able to mention one?
| stickfigure wrote:
| As parent pointed out, the MVC in server-side development
| only shares a name with the MVC in GUI development. Yes,
| MVC is a proven and popular name. But it means different
| things to different people.
| breadwinner wrote:
| Why would it be different? The concept of Models is the
| same whether it is client-side or server-side. These are
| objects that encapsulate business logic. The concept of
| Views is also the same. These are responsible for
| rendering the screen. The concept of controllers? That
| too is the same. Controllers determine application flow
| from one screen to the next.
| jitl wrote:
| The server is typically not a retained-mode kind of
| abstraction. Incremental view maintenance in retained-
| mode MVC systems is the main source of bugs. If you
| render the view from scratch on every request, it's more
| similar to React style immediate-mode UI than something
| like UIKit where you end up handling many UI events and
| keeping little bits of the UI up-to-date with model
| changes incrementally.
| breadwinner wrote:
| You can render the view from scratch on every user
| interaction, even in MVC. In fact, you can use React for
| that purpose. "Lots of people use React as the V in MVC."
| See: https://github.com/facebook/react/tree/015833e5942ce
| 55cf31ae...
|
| Personally, I have not run into large amounts of bugs of
| this type, and I have written plenty of MVC code using
| VanillaJS.
| jitl wrote:
| I mentioned the main problem in the second paragraph:
|
| > There were many bugs in this scale of app around making
| sure the DOM reflected the latest change to some model.
| The engineering team regarded the more complicated
| screens as a nightmare to maintain in our fast paced
| environment with many teams touching the code.
|
| I've seen this same issue in Cocoa/UIKit/Android views.
| Older Cocoa in particular has a lot of hairy wiring up of
| signals and first responders and delegates. I think it's
| less of an issue there because the rate of change is
| typically lower; in web land we expect to deploy
| continuously and with a very high number of engineers,
| anything targetting the app store will usually deploy at
| most weekly (2 orders of magnitude fewer deploys) and
| with many less engineers (usually an order of magnitude
| at least. My hypothesis is the difference in change rate
| is why this kind of bug was more of an issue for web
| developers.
| MrPatan wrote:
| Preach. Angular 2+, btw, can (and should) be used the same
| way. V=f(S) is the only sane way to live.
|
| Just don't change application state from a component
| lifecycle function and you're golden.
| tshaddox wrote:
| I too remember building interactive web sites with jQuery. It
| was never fun creating, for instance, an interactive list
| view where each item can be modified in client state and new
| items can be added. This was the problem for which React
| provided a major "Aha!" moment.
| QuadmasterXLII wrote:
| With modern browsers, " _completely re-output the entire user
| interface_ on every state change " is kinda viable. I
| recently wrote a trebuchet simulator app
| (hastingsgreer.github.io/jstreb) without a framework. instead
| I wrote a "rebuild UI" function that I call on every new
| state, and the user experience is super snappy
| stickfigure wrote:
| It doesn't seem to work at all in Chrome, so maybe not the
| best example.
| QuadmasterXLII wrote:
| Ah, global variables in modules have to be declared with
| var etc in chrome, but firefox and safari let it slide if
| you just assign. Fixed, but I guess I'm gonna have to set
| up a test suite
| nightpool wrote:
| Weirdly I see that changing the "Projectile" selection to
| "P3" and then back to the original "P4" made the range drop
| way down, even though the new value was identical to the
| old value. But changing the "Main Axel" value made it jump
| way back up: https://imgur.com/a/boo5Xw3
|
| So maybe some kind of "non-functional"/reused state issue
| exists regardless?
| QuadmasterXLII wrote:
| Oh, I don't like the look of that. This may be a valuable
| lesson in "I should have just used a framework"
| WorldMaker wrote:
| > 4. Observables (Ember, maybe Angular 2+?)
|
| Don't forget Knockout which was the OG. You can also make the
| case that Svelte, Vue, and Qwik all are different takes on
| Observables (at least as much as Angular 2+ is) all with more
| or less magic and more or fewer escape hatches from
| Observable best practices to imperative(-looking) code.
|
| I got a "What if we did Knockout but with with the compile-
| time benefits of TSX and Pure RxJS Observables?" itch a
| couple months back and have made some wild progress on it. I
| certainly don't think it is ready yet to advocate as an
| alternative to React, but it's probably in an interesting
| A4+B2 tangent on your map right here, and I find that
| interesting.
| jeremycarter wrote:
| I remember 2012, ASP.NET MVC Razor pages, combined with
| individual page knockout Js. Actually worked quite well.
| Infact that system is still running for that company. Sure
| we could have made a angularJS 1.0 SPA at the time, but
| knockout meant we only had to apply the pattern to the
| pages that needed it.
| WorldMaker wrote:
| I even used Durandal some in those cases where we really
| did want a SPA, but Knockout was good enough. That was
| something I appreciated about Knockout too was that the
| SPA framework was _around_ it, not a part of it or
| implemented inside of it. Same with routing frameworks
| like Crossroads.js if you wanted something lighter than
| Durandal for just boring hash-navigation somewhere in the
| boundary spectrum between full SPA and MPA.
|
| It was something that was also attractive about early
| React that React was similarly _just_ a view engine and
| could do MPA or SPA or things in between and it didn 't
| try to have the full kitchen sink. I don't know exactly
| where React stopped being that, but it always feels
| harder to argue that current React is "just" a view
| engine.
|
| In the larger context here with this article, libraries
| that are _just_ view engines should be _great_ for
| building the internals of Web Components. (I 'm hoping
| the view engine I've been working on might serve that
| role well, though with a dependency like RxJS I'm not
| sure if it would be towards the top of the list for many
| developers. It will certainly feel bigger than Lit, for
| example, no matter how well it tree shakes.)
| recursive wrote:
| I got the same itch. Here's my thing.
| https://mutraction.dev/
| WorldMaker wrote:
| Interesting, thanks. Your mutation tracker isn't enough
| like "pure" RxJS Observables for my tastes and what I've
| been doing with my itch, but you captured a few of the
| things I'm covering in my system and are probably the
| next closest I've seen to what I've been doing (and I
| tried to research a deep dive). I think the only other
| thing is that I took an approach that observable change
| bindings look different from static HTML-like attributes.
| I did that in part because that's how Knockout used to do
| it, and also in part because I _think_ it should better
| facilitate SSG /SSR/progressive enhancement when I get
| back around to those ideas (it's not a current priority,
| but definitely an idea I'm tracking).
| recursive wrote:
| I was also influenced quite a bit by knockout. SSR was
| explicitly not a goal of mine. To me, SSR as a feature in
| a framework like this is mostly interesting in the
| context of server/client continuity like rehydration. But
| I have a feeling the constraints imposed by anything like
| this aren't going to be worth it. If I was doing pure
| server rendering, flat text templates seem like the sweet
| spot, since it's fundamentally not interactive. Render to
| html string and ship it. And if I was doing that, I
| probably would not choose to use javascript or
| observables/signals.
| api wrote:
| I used Knockout to implement the very very _very_ first
| ZeroTier network control dialog. Nice paradigm, but I think
| React beat it when things got really complex.
| pcthrowaway wrote:
| > (B) Advocate a framework other than React that uses the
| same pattern as React, but improves the usability. I think
| the two places there is the most room for improvements are:
|
| > 1. Animations
|
| > 2. useEffect() in general
|
| I'm not normally one to "shill" a web framework, and I still
| mainly use (and love) React, but I'm curious if you've tried
| Svelte, because it _definitely_ manages animations better
| than React, and has a different idea of state that 's more
| ergonomic for many use cases (though I won't go so far as to
| say it's definitively "better" than useEffect)
| Vinnl wrote:
| To add to that, one of the (largely justified) criticisms of
| React is that it, or at least the way it is commonly used,
| can have negative performance impact, and thus negatively
| impacts user experience. However, user experience is broader
| than just performance, and critically also includes that the
| application has as few bugs as possible and works well in the
| first place, and I feel that the model you describe greatly
| helps there, _and_ it makes unit testing and strict static
| typing feasible to boot.
|
| (Admittedly, these benefits haven't been thoroughly
| researched, as far as I'm aware, so it still mostly relies on
| gut feeling and experience.)
| techpression wrote:
| I would say SolidJS does everything better than React while
| keeping with the same general mindset. React spent way too
| much time worrying about DX to the point that now DX is
| really bad. Fine grained granularity is such a breath of
| fresh air to work with after the very large and very heavy
| brush that is the React "render the world every time anything
| changes" method (yes they try to be smart about it, but so
| far haven't succeeded, the next compiler might solve it, but
| then we're back to a black box of incomprehensible code soup
| to debug).
| vmfunction wrote:
| Thank you. Finally someone mentions Solid, it got all the
| good part of React, and none of the bloated parts.
|
| Personally, JSX is the mainly thing that makes React
| attractive. As JSX is just modern E4X. It really ought to
| be put into the ES standard again instead of this Web
| Component stuff.
|
| Another good JSX implementation (SSR) is:
| https://nanojsx.io
|
| If you just want something light JSX, then this seems the
| way to go for now.
| mustaflex wrote:
| Web components are a bit verbose by themselves but used with a
| library like lit.js you can build a framework agnostic
| component library. Angular and Vue support WC out of the box
| and they have a wrapper for React. I think the only thing
| missing(or not mature enough right) now is SSR. There are
| probably libraries other than lit.js that take the pain out of
| writing WC.
|
| I was skeptical at first but I've seen in production a
| lit.js/WC component library used with React and Angular
| successfully in the banking sector and it works surprisingly
| well.
| austin-cheney wrote:
| As a full time JavaScript developer of 15 years it boils down
| to 2 reasons.
|
| 1. Eases candidate selection. There is no uniform baseline of
| competence in software generally and certainly nothing exists
| for web development. Its often the blind leading the blind, so
| outsource everything to a tool. At the very least, people that
| cannot use that tool are then not qualified to be there if you
| discount absolutely everything else. After all, it isn't as
| though employers are willing to train new developers to perform
| as required, so they need to turn this into a commodity as much
| as possible.
|
| 2. Composition. Most of the people who do web development
| cannot write original software, plan, or organize at the level
| required by modern applications. Employers still need people to
| do trivial things to get text to appear on screen. As the
| demand for these trivial tasks still exists employers still
| need to hire people to do this work, and so they attempt to
| outsource the parts that require higher intelligence.
|
| These beg the obvious question: What will happen when employers
| realize they don't need to overpay developers to do this work
| when half of it can be pushed into content management systems
| and the other half can be pushed into AI?
| djrenren wrote:
| As someone who just had to answer this for my startup, the
| value of React is that it's robust and immensely hire-able. If
| you're looking for frontend developers, the one thing you can
| always expect is at least passable React knowledge.
|
| Everything else, even if it has a better technical fit for your
| project, is likely riskier for your organization.
| pseudosavant wrote:
| Some of the most productive teams I've worked with (not as a
| dev) have been for tech stacks I personally don't enjoy
| using. Java, .NET/C#, React, etc. In practice, I'd rather
| quickly hire a local senior Java/C# dev for 1X than scour the
| interwebs to hire a Golang dev that requires relocation for
| 1.5-2X.
|
| If I was going to learn a language though, I'd probably learn
| Golang. Their rate is so much higher.
| Draiken wrote:
| I find this argument so absurd. If you know JavaScript and
| basic programming, you can use any front-end framework.
|
| We're hyper-specializing people in a specific framework that
| then don't even understand the basics of JavaScript itself.
|
| I already find the divide between frontend and backend
| developers unnecessary the majority of the time. This takes
| it a step further and in turn creates monstrosities like the
| leftpad debacle.
|
| Can we stop with this nonsense? Hire good developers and let
| them spend 5 minutes to learn the god damn framework of the
| week. If your hire can't learn React in a week, I have some
| bad news for you.
| mattlondon wrote:
| Would anyone pick react these days, if they did not already use
| it/know it/think-it-is-what-they-should-use-because-everyone-
| else-does?
|
| I think that is the point. The original "pitch" for react in my
| mind was that it was lightweight and simple. I don't think you
| can say that any more, and I think a lot of rough edges have
| been identified (e.g. hooks fiasco, app state management,
| dependency-hell etc to name just 3) after years of use.
|
| It's the same cycle that always happens. Old thing ossifies and
| grows fat overtime trying to be all things to all people. Then
| some new thing appears that starts with a clean slate and no
| prior expectations that proves popular as a result
| JacobThreeThree wrote:
| It's as you describe, but also the spec and browser support
| landscape has changed.
| davedx wrote:
| React isn't legacy technology. What a perfidious statement.
|
| I can easily justify the reasons I still use React, but I can't
| be bothered writing it out every time some gimmicky front-end
| tech hits HN.
| sesm wrote:
| Every alternative to React roughly fall into one of 3
| categories:
|
| 1. Go back to reactive templates.
|
| 2. Sprinkle directives over plain HTML a-la early Angular 1.
|
| 3. HTML over the wire.
|
| All those ideas pre-date React and React won against them
| back in 2014.
| nicoburns wrote:
| There is also
|
| 4. The React model but with compiler support to improve the
| ergonomics (and with better static checks).
| meiraleal wrote:
| Yes, I agree with him. What's the reason to use React? It is
| over-engineered and too complicated for no clear benefit. It
| takes longer to build an app using react just because you have
| to deal with things that are exclusive to react
| sohzm wrote:
| lit.dev is awesome.
|
| I am a backend dev so I don't really want to get into the
| intricates of React or Angular. But if I need some reactivity for
| some complex element, I use lit. It's awesome
| troupo wrote:
| They don't.
|
| When your tech needs 20 more web specs [1] to fix stuff that
| literally no one has issues with, it means that you will be
| locked in to frameworks that solve these issues.
|
| Literally right now Web Component SSR is a framework-specific
| barely working non-solution. Even the most ardent web component
| proponents have given up and advocate a framework lock-in with
| lit-html and others.
|
| [1] https://w3c.github.io/webcomponents-cg/2022.html
| tauchunfall wrote:
| I recently rebuild some parts of a large APM (application
| performance monitoring) solution to find out how much JavaScript
| is needed to have similar functionality (minus the backend, of
| course), e.g. faceted search.
|
| It's interesting how much of a component system one can build
| only by using `<input>`, `<label>`, and `<form>`. For the
| remaining interactive elements that can't be build easily without
| JavaScript I plan to use Web Components.
|
| For me this is a reasonable 80-percent solution. But for web
| applications with high requirements I would use React and React-
| Aria components/hooks.
| oblak wrote:
| I've been fought by people insisting that if we're using a
| framework, we should be using it for everything, if it has it,
| even when both agree that doing it natively is actually less
| cumbersome. All that in the name of consistency. I think middle
| ground is a good solution.
|
| On topic: I don't think WebComponents are going to "make it"
| until someone builds a nice framework on top of them. React, Vue,
| Svelte, etc. solve a number of problems that are not directly
| solved by Web Components. State management, rendering, routing -
| right now, these are, imho, the high level areas that need solid
| solutions for an UI app to function in any sane way. How much of
| that is solved by going Web Components?
| earthboundkid wrote:
| "Web Components" are the name for a dream, not an actual
| technology. The actual technologies involved -- customElement
| and shadow DOM -- are pretty crappy to use directly, and even
| when hidden behind a framework/library don't buy you that much.
| But people want it to be true that there is such a thing as a
| "Web Component" so the dream lives on.
| spankalee wrote:
| I work on Lit, which I would hesitate to call a framework, but
| gives a framework-like DX for building web components, while
| trying to keep opinions to a minimum and lock-in as low as
| possible.
|
| It's got reactivity, declarative templates, great performance,
| SSR, TypeScript support, native CSS encapsulation, context,
| tasks, and more.
|
| It's used to build Material Design, settings and devtools UIs
| for Chrome, some UI for Firefox, Reddit, Photoshop Web...
|
| https://lit.dev if you're interested.
| troupo wrote:
| > lock-in as low as possible.
|
| As in:
|
| - reactivity. Specific to lit
|
| - declarative templates. Specific to lit
|
| - SSR. Specific to lit.
|
| - context. Specific to lit.
|
| - tasks. Specific to lit
|
| "minimal" and "low lock-in".
|
| Please do not hesitate to call it a framework. If you call
| React a framework, then lit is definitely a framework.
| spankalee wrote:
| Lit's features are internal to each component (except
| context which is being developed as an open community
| protocol with the Web Components Community Group) and there
| is no coupling between components written in Lit. So you
| can port from Lit to something else component-by-component.
|
| Lit is also modular. The template library, lit-html, is
| usable independently and used by other web component and
| non-web component libraries. The reactive custom element
| base class ReactiveElement can be used to build web
| components with a different template system like Preact.
|
| So yes, "lock-in as low as possible".
| troupo wrote:
| This is just splitting hairs in an attempt to pretend
| that lit isn't a framework (or framework-like lib), or
| that it's somehow unopinionated, or that it somehow
| prevents you from lock-in.
|
| Almost all of the things you listed are specific to lit,
| and lit only. So, people who will develop with lit will
| be locked in to lit. Because it's not like you can just
| pop the code you wrote with lit into stencil or ionic,
| and will just work.
|
| > So you can port from Lit to something else component-
| by-component.
|
| I personally saw a huge project ported from Angular to
| React basically doing the same. It's not a testament to
| lit. It's what people have been doing since time
| immemorial.
| meiraleal wrote:
| > I personally saw a huge project ported from Angular to
| React basically doing the same.
|
| Do Angular and React components talk to each other? Lit
| and other Web component frameworks can share components.
| To refactor Lit components into other web component
| framework or raw web component is orders of magnitude
| easier than converting Angular <-> React.
| hmcdona1 wrote:
| I mean they have to be for now - you're just being
| semantic for the sake of it a bit. I will say as a team
| that utilizes Lit for our design system web components
| (which none of our users even need to know or care about
| no matter their framework btw). The Lit team are huge
| advocates of aligning with native standards (now or what
| they might be in the future) and working to establish or
| push them forward. The goal of the project for a lot of
| these issues truly seems to be to eventually not need
| them to be a part of Lit at all.
| veeti wrote:
| How do we know this won't be killed off by Google in six
| months?
| spankalee wrote:
| Honestly, you don't. It's used for many Google projects
| like Chrome, parts of YouTube, Maps APIs, Collab, the
| Google Store, and a ton of internal things, so I think it's
| unlikely, but I understand Google's reputation.
|
| This is one reason why we care so much about low coupling
| and lock-in, and a small, easy-to-understand codebase. You
| should be able to migrate away from Lit very easily, and
| fork or maintain it if necessary. We're also trying to
| build up our non-Google contributors.
| matt7340 wrote:
| I've read that Angular is also extensively used for
| Google internal projects. How do the teams choose between
| Angular and Lit?
| toasted-subs wrote:
| Svelte compiles into WebComponents.
| beebeepka wrote:
| That's good to know. I really liked what I saw last time I
| played with it but it's hard to find many job listings where
| people are using svelte. Almost everything is react and
| surprisingly, at from what I can tell, it's getting even
| bigger share in job postings I used to see. Hooray for
| uniformity, I guess.
| o11c wrote:
| > I've been fought by people insisting that if we're using a
| framework, we should be using it for everything,
|
| Remember the definition of a framework: a framework is just a
| library that does not play well with others.
| jdmg94 wrote:
| Stencil does it, but the resulting web components are still not
| great to work with because of shadow dom and the missing
| standards you can't expect from custom elements. You want
| inline styles? hope your dev remember to drill those down.
| earthboundkid wrote:
| No, they just lock you into one framework per component. I don't
| know why people say obviously false stuff like this about web
| components besides they just really, really want it to be true.
| Yeah, if you're willing to have the same framework on the page
| ten times, you can just chuck them all in separate script tags
| using the custom element API. But if you care about making a
| performant page with progressive enhancement, etc. this is a bad
| strategy.
|
| Even the name "web components" is basically just marketing fluff.
| When people say "web component", they mean using two particular
| DOM APIs: customElement and shadow DOM. Those are both pretty
| niche APIs. There are some cases where they are helpful, but 99%
| of the time, they don't add much to a project versus good old
| querySelectorAll and normal CSS.
| jakelazaroff wrote:
| Author here -- I'm not sure what you mean by "lock you into one
| framework per component". The point is that you can encapsulate
| framework code within web components, not that _every_
| component you write should be a web component.
|
| Let's say you're writing a Vue app and you really want to use a
| library that's only available as a React component. You can
| wrap that library in a web component and use it in your Vue app
| just like you would any other HTML element. The rest of your
| app can continue being Vue, using normal Vue components.
| jdmg94 wrote:
| except you can't use it as a normal component, you can't
| adjust its CSS normally, you have to `&::part()` your way
| around and hope for the best. Accessing through refs is a
| complete blackbox. I work with web components daily and it is
| a hindrance to my daily work, it is very common for people at
| my org to just re-write a component instead of using its web
| component version.
| mmis1000 wrote:
| I also wonder about this. The webcomponent make the style
| completely immutable unless you add part selector
| specifically... how on the earth this is even useful?
| Imagine using an ui library that you can't change the style
| at all. That sounds like a total joke to me. That isn't
| even a sane default that is useful to most web folks that
| make page base on layout that designers gave.
| jakelazaroff wrote:
| I find it very useful for embedding interactive demos on
| my blog that are mostly independent of the styles for the
| rest of the site (for example, the article here). But for
| what it's worth, there is discussion of an "open-
| stylable" shadow DOM mode that addresses those concerns:
| https://github.com/WICG/webcomponents/issues/909
| EnergyAmy wrote:
| Shadow DOM was a mistake. It's a 0.1 version that was
| unfortunately pushed out as a completed standard. Basic
| stuff is missing like your link. The entire thing should
| be deprecated and we should start from scratch.
|
| If you want to embed something that doesn't use your
| page's styles, we already have iframes. Shadow DOM is
| just a half-assed recreation of that.
| Devasta wrote:
| That sounds awful to be honest. A recipe for total loss of
| standardization within an org.
| recursive wrote:
| Any sufficiently large org already has all the
| technologies.
| mmis1000 wrote:
| The biggest problem of web component is that it don't support
| most state injection(for things that rely on contexts, for
| example: tabs) and template instantiation(render function of
| react or scoped slot in vue for example), which literally
| every current popular web framework does. You may pass string
| or number as string to it. But anything more complicate that
| can't be easily serialized? Good luck.
|
| You may add another layer of abstraction on the top of it.
| But that only make you another framework (like polymer)
| instead of actually using web components.
|
| In other word. Web component is useful to encapsulate an
| 'app' (for example: a interactive map viewer that accept an
| address) inside another app. But is mostly useless to
| encapsulate anything other than a simple ui/input component.
| There is basically 0 functionality to inter-blend between
| parent and child components of different frameworks.
| djrenren wrote:
| I've found webcomponents to be really good at encapsulating
| anything that doesn't directly query application state.
|
| Specifically there are two type of components that really thrive
| as web components (as opposed to react):
|
| 1. Highly interactive components - Components that implement
| complex interaction management (but sort of agnostic to
| application state) are ideal web components. You don't need to
| mess around with `useEffect` or `useMemo`. You get really tight
| control of rendering and state updates.
|
| 2. Highly internally stateful components - Components that track
| a lot of state that doesn't escape the component, work great as
| web component. You get strong encapsulation without a framework
| requirement.
|
| React conflates two concepts that I think are better when
| separated: templates, and components. Templates provide a "re-
| render the world" approach, and components encapsulate state and
| interaction patterns. Conflating these two things causes the
| standard useEffect and useMemo headaches. It also means that any
| consumer of your component, must also use your templating system
| (react's render function).
|
| The `lit` library does this separation extremely well, allowing
| you to implement components using templates if you want, or not.
| And consumers do not care how the internals are implemented.
| troupo wrote:
| > You don't need to mess around with `useEffect` or `useMemo`.
| You get really tight control of rendering and state updates.
|
| You don't need those in React either. Whatever you do in Web
| Components can probably (most likely) be done in React.
|
| After all, Web Components are a solidified 2010-era design. The
| reason React has hooks now because people have moved on, and
| are exploring other ways of building stuff. The only mistake
| React did was to keep reactivity on component level (hence all
| the hooks and their weird rules) when most people moved on to
| more granular reactivity. Hell, even Angular did.
| djrenren wrote:
| > You don't need those in React either.
|
| I mean... sometimes you do, that's why they exist. But yeah,
| most of the time you don't.
|
| > Whatever you do in Web Components can probably (most
| likely) be done in React.
|
| Of course! React is a good and powerful framework. But
| everything you do in React can be done in Angular 1.0 or even
| backbone.js. As always with frameworks it's about the
| productivity / performance ratio for your team (or for
| libraries, the ratio for your consumers).
|
| > After all, Web Components are a solidified 2010-era design.
|
| A lot of the web components related APIs are being actively
| developed including constructable stylesheets, shadow DOM
| APIs and more. Regardless, the era of design is not a great
| point in either the "pro" or "con" column, and is usually an
| ambiguous shorthand for the actual quality being critiqued.
| paulddraper wrote:
| > I mean... sometimes you do, that's why they exist.
|
| They exist because they're useful, but you can write
| traditional React components that look a lot closer to Web
| Components, if you think that's better.
| djrenren wrote:
| Forgot to mention, the knock-on effect of this thought process
| is that if you want to adopt web components, you still need a
| templating approach. And you'll find that most of your code is
| templates, and only a few are really components.
| paulddraper wrote:
| > React conflates two concepts that I think are better when
| separated: templates, and components.
|
| Whether a React code base conflates them depends on the code
| base, but the more familiar terminology is _container_ vs
| _presentation_. [1]
|
| [1] https://www.patterns.dev/react/presentational-container-
| patt...
| djrenren wrote:
| You can absolutely follow a discipline like this which
| recreates this separation in a framework that lacks it
| willio58 wrote:
| I completely agree. Recently I listened to a podcast where Brad
| Frost talked about web components being useful for design
| systems, as you can make a button in a web component and have
| that defined no matter what JS framework the dev team (or
| teams) want to use company-wide.
|
| One issue I see though and I almost feel dumb for saying it, I
| don't like how web component code looks. Using innerHTML feels
| really weird when your team is so used to using JSX for react
| components for example. I don't think this would stop me from
| researching web components more but does anyone feel similarly
| or have a solution or obvious answer for me in this area?
| nbe wrote:
| lit [1] provides declarative templates for web components for
| example.
|
| [1] https://lit.dev/
| itronitron wrote:
| For me, it feels weird to have four file types I need to
| manage in order to define a UI, instead of just one.
| zaphar wrote:
| You don't have to use innerHtml. The ShadowRoot pretty much
| acts like a document. So you can also use appendChild.
| Combined with a template element you can completely avoid
| innheHtml. You could even use jsx to create the template
| element I suppose.
|
| That said I think this is mostly a non-issue.
| jongjong wrote:
| I find that they can work very well with state but since state
| is typically passed via attributes (downstream), it means that
| components can only share state with each other via strings. I
| found this to be an advantage, not a drawback because simple
| interfaces are at the core of my coding philosophy and strings
| make it infeasible to pass complex instances or functions to
| other components.
| djrenren wrote:
| Well, this is only sort of true. When you're writing HTML
| you're restricted to attributes but custom elements are
| JavaScript objects and are free to respond to property
| updates on the object. Relying solely on strings is a
| limitation of your templating engine.
|
| For example lit-html templates support syntax like:
|
| <my-element .someProp=${new Foo()}></my-element>
| toasted-subs wrote:
| Pretty excited to see all those job posts for react disappear.
| preommr wrote:
| Web components are a half-baked solution. It only becomes useful
| with another framework (even if it's very lightweight) like lit.
| At which point I might as well use vue/react/svelte since I am
| already brining in a library. Tech like preact is really
| lightweight as well, and given the popularity of react, is enough
| to offset any benefits web components have.
|
| I would really like it if we reached a point where a web project
| only had a single dependency that's a bundler like vite that you
| point to an index file, and that's it.
| OJFord wrote:
| I think we're going in the opposite direction though - everyone
| wants to hide what's going on and use some magic CLI that just
| takes care of everything for you, don't worry about how or when
| or what to do if it goes wrong, just run `flyctl deploy`,
| `wrangler publish` (Cloudflare), `npx wizzle wazzle` :sparkles:
| :tada: never `git commit -m '(chore): [...]'` again!
|
| Oh and here's a readme example of how to set that up if you're
| using pnpm v42 with sveltekit v2 and webpack v99. For any other
| combination of the 5 packagers, 19 bundlers, and 56 frameworks
| commonly in use and giving examples like this recommending each
| other - have fun.
| reidjs wrote:
| I use them for a basic website (no build step) for things like
| navigation components and page templates. They are great for
| that, but not much else in my experience. Once you have a
| complex UI or multiple devs on a project it's probably better
| to just use a full framework
| codegeek wrote:
| "half-baked solution"
|
| Can you elaborate further ? Anything that removes dependencies
| from external libraries is a huge plus for me so I am curious
| as someone who is not great at JS.
| troupo wrote:
| > Can you elaborate further ?
|
| As you read the following, keep in mind that at this time Web
| Components have been in development for almost 12 years.
|
| The core is just three standards, CustomElements, Shadow DOM
| and HTML Imports (already deprecated and removed in favor of
| JS-only imports). And people will go out of hteir way to sell
| you the idea that this is lightweight, all that you need etc.
|
| _However_.
|
| They've already spawned half a dozen new web standards just
| to deal with issues they inflicted on themselves. None of
| these issues are present in any other solution/lib/framework
| that exists.
|
| These range from the fact that web components cannot
| participate in forms (fixed with a new spec:
| https://web.dev/articles/more-capable-form-controls) to their
| inability to share stylesheets (fixed with a new spec:
| https://web.dev/articles/constructable-stylesheets) to
| whatever else (hard to keep track).
|
| They will need _at least 20 more new web standards_ to fix
| other issues that, once again, are not a problem for
| literally every other framework, library, or hand-written
| code under the sun: https://w3c.github.io/webcomponents-
| cg/2022.html.
|
| Among my favorite ones: a web component button cannot be a
| submit button in a form; you cannot reference an id inside a
| shadow root, and that breaks ARIA.
|
| To call them half-baked is an understatement. They are badly
| thought-out, badly implemented APIs with no forethought or
| visible planning, and literally no end goal in sight. The
| people building this met to hash out what more is needed for
| them to be complete only last year, _11 years into
| development_. All development before that looked like ad-hoc
| patches by people surprised that a yet another thing doesn 't
| work, but is sorely needed.
| tannhaeuser wrote:
| In case anyone was wondering, JavaScript per se isn't replaced at
| all. All mentioned examples still use event listeners,
| querySelectorAll, ES modules, and what not. Most importantly, you
| need to subclass HTMLElement and register your custom element
| using JavaScript in the first place eg: class
| MyElement extends HTMLElement { }
| window.customElements .register('my-element',
| MyElement)
|
| (the hyphen in the name is idiosyncratically required by the
| custom element spec).
|
| As such, "HTML web components" (aka custom elements, which have
| be around for many years) are targeted at developers not
| hypothetical web users/authors. Then what is the point? When
| you're relying on JavaScript anyway, you have already much
| greater freedoms - syntactically and otherwise.
|
| Custom element declarations and custom vocabularies can make
| sense as a means to organize and isolate authoring concerns when
| you're creating hypertext documents. The fact alone that you have
| to use JavaScript for registering custom elements make them a
| non-starter though (ie consider an authoring tool which surely
| doesn't want to execute arbitrary JavaScript in client docs).
|
| It's not that there's no precedent either. SGML has a mechanism
| for parametric macro expansion where your element is
| syntactically replaced into an arbitrary markup fragment, with
| type-checked arguments (= attributes at the call site, just as
| with custom elements), and with type-checking the resultant
| expansion in context (ie. checking whether the expansion adheres
| to the content model at the expansion site), also having of
| course the capability to include JavaScript. Moreover, SGML
| actually can serialize/re-parse such markup whereas HTML's
| preliminary APIs for fragment parsing won't deal with contextual
| tag inference at all.
| runarberg wrote:
| For me, being able to offer my library as a web component is
| kind of neat. Sure I can ask users of my library to import it
| then query select math inputs, then apply my library on these,
| and remember to apply it also on DOM change.
| <script type="module"> import lib from
| "/path/to/my/lib.js"; for (const target of
| document.querySelectorAll(".target")) {
| lib(target); } // TODO: Watch for DOM
| change and apply lib. <script> <span
| class="target">Some Input</span>
|
| Or I can simply ask them to import my web component module and
| use the custom element: <script
| src="/path/to/my/web-component.js"></script> <my-
| lib>Some input</my-lib>
|
| The latter certainly feels like a superior API for my users.
| svieira wrote:
| Or you can do a little more work in your lib for your users
| and offer: <script type="module">
| import lib from "the-lib.co.uk"; lib({ target:
| ".target" }); </script>
|
| If your users might not want you to watch the _whole_ DOM for
| performance reasons: <script type="module">
| import lib from "the-lib.co.uk"; lib({
| target: ".target", root: ".all-the-targets-show-
| up-here" }); </script>
|
| And if your users might already have a mutation observer in
| their apps: <script type="module">
| import lib from "the-lib.co.uk"; lib({
| target: ".target", observer: theAppObserver
| }); </script>
| runarberg wrote:
| It may just be me, but all of these seem a lot inferior API
| design then a simple web component. Particularly if I'm
| asking my users to setup a mutation observer.
|
| Aside: Don't you need to pass the library function into the
| callback while constructing the mutation observer?
| import lib, { mutationObserverCallback } from "https://my-
| lib.example"; lib({ target:
| ".target", observer: new
| MutationObserver(mutationObserverCallback), });
|
| Honestly, this feels like so much magic compared to a
| simple: <my-lib>Some Input</my-lib>
|
| where I handle update in my library by listening to the
| slotchange event.
| megaman821 wrote:
| I don't feel like web components and React should compete for
| most people. Web components feel pretty good at making leaf
| components, especially when they will be used with multiple
| technologies. I tried using React to only make a single component
| for use within a larger React app and within a Django site, and
| it was not as smooth as a web component. Also, I tried to make a
| web component app and there was way more friction and less
| tooling than a React app. As it stands now, I wouldn't use React
| for single component nor web components for an entire app.
| r3trohack3r wrote:
| For folks looking for a lightweight JS class that manages the
| lifecycle of Web Components, I have this little Template class I
| use in many of my front-end projects. It's able to manage the
| application state by pushing the state down through the
| application and bubbling changes up.
|
| It's a 161-line file that's easy to reason about and modify as
| needed.
|
| https://github.com/retrohacker/template
| switchbak wrote:
| I haven't been in the frontend world for many years now, but I
| come from the mid-90's world of GUI development / game engines /
| old school desktop stuff.
|
| I look at this stuff, and just think how sad it is that we
| haven't progressed beyond the state of gluing together freakin
| low level divs and spans within some JS code with callbacks
| galore.
|
| For some reason I thought we'd have made it beyond that by 2023,
| and we could talk declaratively at a high level about the kinds
| of interfaces we want to render and where the data lives.
| Hopefully I'm wrong and the magic is buried under some Elm tree
| or a React library or something.
|
| Something something get off my lawn...
| metadaemon wrote:
| It's a very complex problem to solve and I think a lot of
| people need to accept that. There will never be a simple
| solution with a low learning curve that's actually performant
| for non-trivial applications without a fundamental shift in
| browser technology.
| rglover wrote:
| There is. I was frustrated by all of the chaos and built a
| solution [1]. Not too far off from an RC1 and then a 1.0
| (which is being done slowly so I can freeze APIs and avoid
| the typical JS rug pulls).
|
| [1] https://github.com/cheatcode/joystick
| myaccountonhn wrote:
| I think elm showed that it is possible to build a solution
| with a low learning curve.
|
| Sadly elm hasn't really taken off but as far as frontend
| goes... it is just so simple together with elm-ui.
| agloe_dreams wrote:
| The problem is CSS. CSS is so freaking complex with millions of
| possible outcomes. https://www.w3.org/Style/CSS/all-
| properties.en.html
|
| Building a declarative UI that compiles to that sort of
| declaration means building that from scratch. We do currently
| work like that though. React isn't that far and web components
| built into an element of that.
| deergomoo wrote:
| I wonder how different things would look if you could opt out
| of the cascade for CSS. It's great for documents but
| signifcantly less so for "apps", where the widget is the
| widget and by-and-large should not be affected by the other
| bits of interface it's inside.
|
| I think that's why frameworks like Tailwind etc. have got so
| popular -- they're much closer to the traditional native
| application way of styling. You set all the appearance
| details on the component and then you reuse the component,
| styles and all.
| 11235813213455 wrote:
| that's how it is if you're using high-level react components or
| web components, it's just an XML-like layout, user-friendly.
| What the article is showing is their low-level implementation,
| but as a consumer you can just import and use them
| mattlondon wrote:
| I think you are talking about web components.
|
| Even in the old desktop world _someone_ had to build the button
| widget (and all the others) that let you just throw stuff
| together in MFC or Swing or whatever.
|
| Same today - someone has to build the web components in order
| for us to declaratively use them as high-level Lego.
|
| Trouble is, there is no real high-level "general purpose"
| library of components beyond the core HTML elements (they'll
| get you a long way but there are notable things missing that we
| expect from apps, e.g. toolbars, menus, tab strips etc), and
| then the probably reason for their not being a general high-
| level library is that everyone wants something special for
| their websites (because historically websites have always
| allowed a lot of design flexibility, way more than your typical
| win32 app ever did for example).
|
| I have several times really wished to have some solid "desktop
| style" components to use for things like menus, tool bars etc.
| That would make prototypes in electron/neutralino/tauri way way
| way faster to do.
| jacobsimon wrote:
| There are certainly lots of great component libraries out
| there for various frameworks that help with this, but I agree
| with the parent comment that it's still not the kind of
| progress we should have had by this point. I think it's
| unfortunate that we have to stick to HTML/CSS as the
| foundation for everything to maintain compatibility and
| accessibility, but that's how the web works I suppose. If we
| were to design the web from the ground up today based on what
| people use it for, it would look pretty different I think.
| megaman821 wrote:
| I am not sure it would look that different. It would be
| more consistent with terminology. Things like SwiftUI and
| Jetpack Compose look a lot more like HTML and CSS than
| their predecessors, and there is nothing forcing them to go
| in that direction.
|
| The biggest difference between other major platforms and
| the web, is that the web doesn't come with a default UI
| framework. The primitives for building UI on the web are
| pretty good though.
| jacobsimon wrote:
| Yeah maybe it's a grass-is-greener situation, but from a
| quick look at SwiftUI and Jetpack Compose, they both seem
| to have a lot more in common with React than HTML/CSS
| itself. They seem to encourage functional UI that
| combines state management, event handling, and view
| layout. They have primitives like `Text`, `Row`,
| `Column`, `Spacer`, etc.
|
| I do think the web is a lot easier to learn and the on-
| ramp is so much faster compared to older mobile UI
| frameworks, so it makes sense that they're sort of
| evolving toward the same patterns.
| mattgreenrocks wrote:
| > Trouble is, there is no real high-level "general purpose"
| library of components beyond the core HTML elements
|
| This is why I hate making web UIs.
|
| > then the probably reason for their not being a general
| high-level library is that everyone wants something special
| for their websites
|
| This is why I hate using web UIs.
|
| At this point it's hard not see this as a fully self-
| inflicted wound by the platform. I know there are component
| libraries, but the work always remains fragmented because
| someone decided that their buttons needed purple highlights
| while someone else's needed drop shadows.
|
| And the devs seem to love staying at this low level of
| abstraction. Feels like they had to be dragged into the
| component model espoused by React et al over many years.
| ecmascript wrote:
| I do front end stuff for a living and have been in the
| javascript space for several years. I do other backend
| development as well and I can't see why people think like you
| honestly.
|
| Most other GUI libraries is in a much worse state than front
| end web dev. That is probably also the reason why people use
| front end tech to make native apps today, because you can
| customize and make apps much faster than in basically any other
| way.
|
| I think front end gui development is very easy today and very
| powerful as well and we have progressed a lot. Making stuff
| with web components isn't event that hard and if you want you
| can just use one of the many available syntax sugar libraries
| that exist like Lit and others.
| Devasta wrote:
| Devs use web frontend tech because it is installed on every
| machine, will never have anything less than the full backing
| of the browser devs for the next hundred years, and gets
| around corporate filters. No need to deal with IT security
| losers to get your app installed, no need to get ports
| opened, just everything down port 443 until the end of time.
|
| INTERCAL could win with that feature set.
| paulddraper wrote:
| I think you missed the point.
|
| > why people use front end tech to make native apps today
|
| Even when you have to deal with IT security losers to get
| apps installed, implementing it w/ web tech is extremely
| popular.
|
| E.g. the #1 IDE by popularity [1] is a _desktop app_
| developed with _web tech_. (And yes, it was later ported to
| browsers, but it didn 't start there.)
|
| [1] https://survey.stackoverflow.co/2022#section-most-
| popular-te...
| mardifoufs wrote:
| Exactly. I'm starting to understand the push for web UI now
| that I've started to use qt for a small GUI. I'm sure qt is
| good for some type of apps. But for my smaller scale project
| where the graphic interface is not where we want to spend
| most of our dev time, I'd rather take javascript/react at
| this point.
| josephg wrote:
| I feel the same after playing with SwiftUI and UIKit on iOS
| and trying to make something simple like a text editor with
| a hideable keyboard. The whole platform feels half baked,
| with various overlapping features that each have serious,
| barely documented drawbacks and bugs. "I'm getting a
| warning about my constraints being defined badly" "oh just
| ignore that - you can't make it work without that warning".
| "Everything in my project looks the same as the example but
| mine doesn't work" "Try deleting your constraints and re-
| adding them. Sometimes Xcode is just buggy like that". "I
| tried but Xcode hard crashed". Etc.
|
| The web feels downright cohesive, stable and well
| documented in comparison.
| whartung wrote:
| > Most other GUI libraries is in a much worse state than
| front end web dev.
|
| I'm certainly not going to suggest you're wrong. But I would
| like a sincere comparison between JavaFX (because I sorta
| know it) and "the web".
|
| Maybe its unfair, since the Web is "just the DOM", an empty
| vessel many of the other techs are built upon, which is why
| there's so many options.
|
| I'm not a front end person, by any means, and have been
| striving to make things work with FX. I mostly "get" FX, how
| it does things with its containers and layouts and properties
| and bindings and events and UI thread. It has CSS, I mostly
| don't use it (better living through gray!).
|
| The web, honestly, intimidates me. It intimidates me with its
| vast variety, its complex build processes, the apparently
| galaxy of dependencies and tools and what not. Cross browser
| stuff terrifies me. And maybe that's the wrong reality, but
| that's the impression I get.
|
| I'm managing to Forest Gump my way through FX, but I have a
| Java background.
| shortrounddev2 wrote:
| I'm less cynical about web development. Lots of software
| engineers bemoan writing web interfaces and pine for the days
| of native GUI development, but web won because it's extremely
| accessible to people without CS degrees. There just isn't a
| good native framework that's as forgiving and easy to learn as
| HTML, JS, and CSS. I think gtk is pretty decent though
| yCombLinks wrote:
| Hard disagree, web won because of the deploy story. Users
| don't have to install anything. Html and css is a terrible
| API for app layout, because it wasn't designed for that
| josephg wrote:
| Given how important the web's deploy story has been for its
| success, I'm surprised we haven't seen more zero deployment
| application platforms / prototypes appear. Docker is an
| attempt at something similar on the server, but docker
| images are huge and docker still separates its docker fetch
| and docker run steps.
|
| Maybe part of the problem is that the web is the only
| platform where people obsess over the size of deployed
| artefacts. Websites are certainly getting bigger, but
| they're still an order of magnitude smaller than the
| average snap package or iOS app.
| shortrounddev2 wrote:
| > Html and css is a terrible API for app layout, because it
| wasn't designed for that
|
| And yet it's so easy and forgiving that millions of 13 year
| olds learned it for their myspace and tumblr pages over the
| last 15 or so years.
|
| Somehow, despite all the CS graduates and 20 year software
| engineering veterans bemoaning it, more and more people
| learn HTML, CSS, and Javascript every day while the number
| of people learning native GUI development struggles to keep
| up or outright fades away. I truly believe that most
| software engineers don't understand what ergonomic software
| or programming languages look like. They're blinded by
| their expertise
| yCombLinks wrote:
| Those aren't apps, they're closer to documents, which is
| what it was designed for.
| paulddraper wrote:
| Do elaborate on what UI paradigm web browsers ought to use from
| mid-90s GUI development.
| usea wrote:
| They said things should be better than they are, not that we
| should go back to the 90s or even use it as inspiration.
| paulddraper wrote:
| Oh well, yes, it would be nice for things to be better than
| they are.
|
| (^ feel free to copy-paste that to any HN thread)
| aegypti wrote:
| It would be nice for conversations to be kinder, less
| snarky, and more curious. Could even edit out any swipes
| and internet-style cross examination as well.
| btbuildem wrote:
| I don't really do FE anymore, but I've worked in that realm
| long enough to see several frameworks come and go - as well as
| see the JS ecosystem scale far beyond the limits of its
| organizing principles.
|
| In my opinion, the community is lacking foundations, structure,
| and principles - something that would otherwise be instilled by
| formal education. JS is fantastic for exploring how programming
| works, it makes it easy to stitch things together, and the
| barrier to entry is basically zero; all you need is a text
| editor and a browser.
|
| The flipside is that people regularly reinvent things, same
| sets of ideas get formed and re-formed, fall into and out of
| vogue over and over again. It is true that there is great
| complexity to be dealt with in this domain, but it feels like
| whenever the current set of tools and practices matures enough
| to face some of the hard problems, the instinct in the
| community is to "start from scratch" and before long some new
| shiny exciting thing appears. It shows a lot of potential, it's
| nowhere near facing the hard problems, people jump on the
| bandwagon, time passes, and the new set of tools and practices
| arrives at precisely the same place.
|
| Web components have been in the works for a long, long time.
| The inherent competition between the major frameworks divides
| people into camps, which doesn't help. But, seeing the slow but
| steady progress in the web components realm indicates to me
| that they're apart from the patterns I was ragging on in the
| previous paragraph. They increasingly seem to deliver on the
| promise of creating advanced building blocks - perhaps one day
| a developer won't have to choose between a React Table, a Vue
| Table, a Gobagool Table, etc, but use a plain vanilla standard
| issue web component table to display their CSVs.
| brlewis wrote:
| From the article, <Card> <Avatar />
| </Card>
|
| This is talking declaratively at a high level about the kind of
| interface to render. Lots of component frameworks look like
| this example. Thinking "how sad it is that we haven't
| progressed beyond the state of gluing together low level divs
| and spans" sounds like a preconceived idea rather than a
| response to this article.
|
| By the way, I come from mid-80's BASIC on 8-bit home computers.
| _You_ get off _my_ lawn.
| jacobsimon wrote:
| Not OP but at the end of the day, custom components like this
| still have to be rendered down to primitive HTML and CSS, and
| are plagued by all sorts of browser-specific issues and
| conventions that make higher level abstraction way more
| difficult than they need to be.
|
| As a random example, HTML specifies that clicking a
| `<button>` inside a `<form>` automatically submits a POST
| request to the current URL. We can't change that because it
| will break a lot of webpages that rely on this default
| behavior, so now every component system built on top of
| <form> or <button> needs to prevent the default browser
| behavior, and there are so many more examples of things like
| this.
| mattgreenrocks wrote:
| The problem with many front and backend web frameworks is they
| love the medium of the web too much. This might sound absurd,
| but they leak all sorts of web gunk through and then pile their
| own concepts on top.
|
| A simple example of this is most backend frameworks let you
| signal an error by throwing an exception. Good choice! Except
| when you go to throw one, you often have to choose from a bunch
| of HTTP status codes to bundle with your exception. I want to
| tell the user that validation failed, that's all. I should
| throw a ValidationError, not a HttpResponseError. They're not
| really abstracting anything, just adding a layer of structure,
| usually via libraries that are glued together.
|
| Similarly, I've started to be of the opinion that the ideal
| HTTP request handler has very few HTTP-specific details in it,
| as the framework can introspect the types and annotations to
| determine how to pass data in and out. This is very different
| from typical frameworks which are happy to hand you raw
| requests and responses and tell you to do it all. Nothing wrong
| with that for special cases, BTW, except for people's tendency
| to mix HTTP, infrastructure (DB/messaging/APIs), and business
| logic in the same handler.
|
| There will always be cases where you need direct control, but
| I've been moving towards stacks that automate most of this to
| cut down on the gunky makework feeling I get when doing webdev,
| and it has been integral to me actually enjoying the tooling
| rather than feeling like I'm filling out TPS reports. Currently
| that's Spring Boot + Kotlin, despite the enterprise stigma the
| JVM and Spring have.
| EMM_386 wrote:
| > Something something get off my lawn...
|
| While I agree, this is what we're stuck with. I have 25+ years
| of experience. Before JavaScript and CSS existed.
|
| Now? I'm on an Angular 16 (moving to 17 SPA).
|
| Worked with almost everything else in between.
|
| I had all the same feelings. "We're doing _what_ with
| JavaScript now?? ".
|
| It turns out, it's not all that bad. TypeScript is pleasant
| enough, for me Angular is logical, and sure at the end of the
| day it's all just HTML/JS/CSS but what can you do?
|
| We're stuck with it, unless WASM totally up-ends the entire
| thing and we have JIT'd languages like .Net and Java running on
| the client ... which is ...
|
| Well, I'm not even sure what that is anymore. It's not HTML,
| JS, and CSS!
| davetron5000 wrote:
| Web Components are not a replacement for React. They are a thing
| you would use to build React if you were to do so today. To use
| only Web Components, you will be writing a lot of low-level code
| using the browser's API, or you will have to use a framework
| built on Web Components
| troupo wrote:
| > They are a thing you would use to build React if you were to
| do so today.
|
| No, you wouldn't. Very few JS frameworks (however new they are)
| use web components as their foundation for many, many, _many_
| reasons.
| dberg wrote:
| unrelated to the content, but what a gorgeous font that is
| pvorb wrote:
| I'm mostly distracted by it. The cursive parts in particular
| are distracting me from the actual content, so, while it looks
| somewhat nice, it does a disservice. At least that's the case
| for me.
|
| A good font should go out of my way in my opinion. When I don't
| notice it at all, the font is perfect. Android default fonts
| definitely fall in this category, for example.
| 3cats-in-a-coat wrote:
| No they don't eliminate anything. Framework never HAD to have a
| lock-in. They WANT to have a lock-in. They want to have a flashy
| site, with short sexy demos, and to give you slogans to repeat,
| and create in you a sense that all your struggles as a developer
| were caused by %PREVIOUS_TECH%, that you've been wronged and now
| you get to be a part of a revolution.
|
| And they want to CAPTURE you. This is why 99% of frameworks have
| a deliberately monolithic and isolating architecture, where it's
| all in, or all out. You don't want to miss the revolution are
| you? Are you stupid? Of course you're not stupid. So now your
| apps are locked in.
|
| And Web Components won't stop frameworks from finding highly
| specific ways to be "useful" in a way where you need to do
| everything in them.
|
| The solution is to know how to architect your app and stop
| believing marketing BS. Otherwise you'll keep fleeting to the
| Next Big Thing (tm) and never realize why it always ends the same
| way.
| auggierose wrote:
| As far as I can see, web components take only strings as
| arguments. That alone disqualifies them from being a serious
| component framework. I've looked at them only for a short time
| last month, because I was excited about a web native component
| framework, but they provide basically nothing I would expect from
| such a framework. They are not even in the same arena as React.
| djrenren wrote:
| > They are not even in the same arena as React.
|
| This is 100% correct. I think a lot of the disappointment about
| web components comes from a mismatch in expectation between the
| spec writers and what people when they think "components".
|
| Web Components allow you to make new HTML elements. That is,
| you can make new kinds of DOM nodes out of other DOM nodes.
| This is powerful, but the resultant API is still a DOM-level
| API, and not a full templating system like React.
|
| On the other hand, because all these templating systems (React,
| lit, svelte, etc.) ultimately boil down to a series of DOM
| manipulations, this allows you to create a kind of element that
| can be plugged into all of these systems.
|
| Custom elements are a lot more akin to the C ABI. Than a fully
| featured framework.
| WickyNilliams wrote:
| Strings as _attributes_, yes. But that's par for the course
| when it comes to html (boolean attributes aside).
|
| However, anything can be passed as a _property_. React operates
| on properties by default (hence `htmlFor` and `className`, not
| `for` and `class`). In fact, react's upcoming improved WC
| support will first do an `in` check on a property name before
| falling back to attribute. This is similar in vue etc.
|
| So yes if you're only authoring plain html you're confined to
| primitives, but if you're using a framework or WC lib, they
| almost certainly support properties
| auggierose wrote:
| I see, interesting. That's certainly helpful. Still, I don't
| see what problem web components solve. New custom html tags?
| Nice, but useless. And if I have to use a framework or WC lib
| on top of web components... Well. Nothing gained, it is just
| switching one framework for another. I am not against that at
| all, in fact I am writing my own framework for specific
| reasons. But let's not pretend that web components are a
| solution to anything, or that there are specific reasons why
| it needs to exist.
| jatwork wrote:
| Do we see a future where the web development free of these
| frameworks?
| sesm wrote:
| When browsers implement some API to efficiently synchronize
| state with UI a-la React.
| jdmg94 wrote:
| > We've seen a lot of great posts about web components lately.
|
| where? I work at a fairly big org that some time ago decided to
| bet on web components. Everyone I work with (including me) hates
| it.
| itslennysfault wrote:
| I like the idea of web components, but really dislike html and js
| being intermingled (the reason I don't like React/JSX). In web
| components its even worse because its HTML as a string which
| means it has no validation and isn't syntax aware. I much prefer
| the angular approach where you have separate css,html,ts files,
| and would love a web component framework that could work
| similarly.
|
| Searching for this I found some kinda hacky solutions on Stack
| Overflow which use fetch to load html/css at runtime.
| paulddraper wrote:
| > its HTML as a string
|
| Can you explain what you mean by that?
| IshKebab wrote:
| React uses JSX/TSX which is much better because it is syntax
| checked and even type checked in the case of TSX.
| thfuran wrote:
| Html as a string literal in code rather than the html being
| in a separate .html file.
| itslennysfault wrote:
| This is the example from the article, and pretty common
| practice for web components. As far as an IDE is concerned
| this is just a string of text (it doesn't know/care that it
| is html). This makes it more error prone as the IDE can't
| catch syntax errors in the html.
| connectedCallback() { this.shadow.innerHTML = `
| <p>Hello from a web component!</p> <style>
| p { color: pink; font-weight:
| bold; padding: 1rem; border: 4px
| solid pink; } </style> `;
| }
| paulddraper wrote:
| Well, you _can_ use `innerHTML` and a string, but you don
| 't have to.
|
| But there several alternatives:
|
| 1. Use DOM APIs (createElement).
|
| 2. Fetch the HTML as a separate resource.
|
| 3. Have the HTML in a separate file and bundle it with a
| bundler.
|
| 4. Use React/JSX.
|
| 5. Use a preferred templating library of your choice.
|
| You can do whichever of these you like the most
| claytongulick wrote:
| If you use a good rendering library, like lit-html then (at
| least in vscode) you get very nice syntax highlighting,
| completion and validation: html`
| <this is all syntax highlighted> `
| itslennysfault wrote:
| I was actually just looking at that after posting this (lit
| is new to me). That's a pretty cool solution. I'd still
| prefer an option to have the html in its own file, but that
| is just my taste. I know a lot of people feel exactly the
| opposite.
| claytongulick wrote:
| Maybe a bit pedantic - but I prefer using lit-html, not
| lit.
|
| Lit is a bit too "frameworky" for my taste, I generally
| just use vanilla classes that extend HTMLElement and have a
| render function that renders the lit-element template to
| the light dom.
|
| Something like: import {html, render}
| from 'lit-html'; class AppComponent extends
| HTMLElement { connectedCallback() {
| this.template = () => html`<markup here>`;
| this.render(); } render() {
| if(this.template) render(this.template(),
| this) } }
| customElements.define('app-component', AppComponent);
| fuzzy2 wrote:
| Then... use Angular Elements?
|
| Using _innerHTML_ isn't specific to Web Components in any way.
| It was and is a quick & dirty way to dynamically insert HTML.
| yohannparis wrote:
| You can use `<template>` for that purpose and keep your
| separation of concerns okay.
| MrDresden wrote:
| As a non web dev I had to look this up and yeah, this looks
| like a very sane and clean way to separate concerns and get
| proper handling from IDEs:
|
| https://developer.mozilla.org/en-
| US/docs/Web/API/Web_compone...
| djrenren wrote:
| Web Components are really just the minimal APIs required to
| allow the implementation of new HTML elements. This includes
| things like:
|
| - Responding to being attached to the DOM
|
| - Encapsulating DOM nodes (the Shadow DOM)
|
| - Scoped styling (Shadow DOM + User defined stylesheets + CSS
| parts)
|
| It is definitively not a templating engine. It doesn't provide
| any new APIs for creating DOM nodes, or mutating them a la
| React or handlebars or lit-html. Templating is basically the
| "next step up the stack". Using shadowDom.innerHTML = `...`; is
| basically a stand-in for having an actual templating engine.
|
| There is work going on, developing a native templating system
| in the browser which may interest you. It's called the DOM
| Parts proposal and you can find info on it here:
| https://github.com/WICG/webcomponents/blob/gh-pages/proposal...
| jacobsimon wrote:
| I like React but I actually agree with you re: JSX, it helps me
| to remember that JSX is 'just javascript' - it's a syntactical
| shorthand for creating a component tree, which then happens to
| be rendered into HTML.
| acheong08 wrote:
| Rather than putting the HTML in JS, you can fetch HTML in the
| JS.
|
| E.g. https://github.com/g-utils/WebComponentFactory
| byyll wrote:
| I wonder how the preview on hover was made.
| adam_arthur wrote:
| People discussing writing Web Components by hand are missing the
| point.
|
| Web Components, once adequately specced, will become a compile
| target for higher level frameworks like React and Vue. That way
| you still get the benefits of higher level frameworks but the
| components can interoperate with each other. Vue CLI already
| supports compiling down to a WebComponent, though not sure how
| first class it is.
|
| There are far too many lacking ergonomics to expect writing Web
| Components by hand to become popularized/convention
| jdmg94 wrote:
| I work at a big org and we use Stencil to produce UI kits using
| web components. In my experience and the anecdotal experience
| of the people in adjacent orgs that work with web components
| too: Its still a shit show.
| adam_arthur wrote:
| Yes, the Web Components spec is incomplete and not adequate
| for real-world use currently.
|
| But the end state will be as a compilation target, not as a
| development platform.
| troupo wrote:
| We're still at least 20 specs away from them being
| "adequately specced": https://w3c.github.io/webcomponents-
| cg/2022.html
|
| And there are multiple other issues that make web
| components a very unattractive compilation target.
| claytongulick wrote:
| I've been using Web Components in production for years with great
| success.
|
| My guiding principles:
|
| - Avoid shadow dom unless it's a library. Stick with the light
| DOM and css system of your choice.
|
| - Use lit-html or similar for rendering
|
| - Use class properties for reactivity (add a render() call to
| setters, as needed)
|
| - Ignore attributes entirely. Just use properties.
|
| - Don't bother with composable components and slots. You
| generally don't need them
|
| - Use a nice router like vaadin or ionic or similar to hoist
| components and support deep linking
|
| - Let components maintain their own state. Structure the dom so
| that it's easy to grab state from a component with querySelector.
| If this doesn't work, I have a little state lib called
| ApplicationState[1] that works great.
|
| - Really think about what needs to be a component vs normal html.
| Don't overdo it with components.
|
| - Structure the app with high level "scene" components that map
| to URL deep links, and app components that you use to build the
| scenes. Scenes are targets of the router.
|
| [1] https://claytongulick.github.io/applicationstate/
| djrenren wrote:
| Please remember that Web Components are much more akin to an ABI
| for web projects and not a full-featured framework.
|
| Any web component easily plugs into React, svelte, lit, etc.
| Existing components written in those frameworks can pretty easily
| be wrapped in a web component. It's a common base-layer we can
| all use.
|
| If you attempt to build a web app using just web components and
| no libraries, you'll quickly find that you're doing lots of
| manual DOM updates (no templating engine) and lots of manual
| state management (no data management API).
|
| As an ABI, it's wildly successful. It does, in fact, just work.
| It's just very low level.
| riquito wrote:
| It's not all that shiny. Web components have global names (you
| should pretty much apply a prefix/namespace if you want to work
| with others) and managing multiple version of the same component
| in the same page is an issue in any non trivial codebase (either
| use a different name per version or fix all breaking changes at
| once during the upgrade, unless the draft about scoping web
| elements became standard
| https://github.com/WICG/webcomponents/blob/gh-pages/proposal... )
| chiefalchemist wrote:
| > To prove it, we're going to do something kinda crazy: build an
| app where every single component is written with a different
| framework.
|
| Interesting exercise. But now I wish she/he would one-by-one
| replace each framework with web components, so that in the end,
| there are no frameworks, only web components. As in, "Oh shit!
| We're going to abandon Vue (or React, etc.) and replace it with
| web components" or "We've been taked to only use web componentst,
| and no frameworks." What does that migration / transformation
| look like? Isn't that a likely scenario?
| iteratethis wrote:
| I don't think there's a need to cause a stir and generate hate
| for either Web Components or React.
|
| We should hate both equally.
|
| Either approach is frankly an embarrassing way to build complex
| interactive applications. Web tech is just way too low level,
| batteries not included. We've added mountain of complexity to
| deal with it but it doesn't hide that the fundamentals are broken
| and that productivity is low.
| socketcluster wrote:
| The main problem with the Shadow DOM which makes people avoid it
| is the inability to use CSS externally to style the elements
| which are generated internally by the component...
|
| This is unfortunate because the Shadow DOM is essential if you
| want to work with child components slotted into it from the
| outside. This opens up many use cases.
|
| There is one alternative which is not being considered; it's
| possible for components with a shadow DOM to inject their
| elements into the Light DOM (where they can be styled/skinned
| externally with CSS), you just have to make the user slot a div
| (or other element) from the outside to act as a 'viewport' so
| that the component can inject its children into it (instead of
| injecting them into its Shadow DOM).
|
| With this approach, you can still access slotted elements. It's
| an ideal pattern for situations where you want the component to
| generate child elements from a slotted template.
|
| I wrote an article about this approach here:
| https://dev.to/jondubois/web-components-the-template-viewpor...
| djrenren wrote:
| This is a great approach for components that want to inherit
| all styling from their context.
|
| In cases where you want to introduce just a little styling, the
| CSS Parts API is really cool: https://developer.mozilla.org/en-
| US/docs/Web/CSS/::part
| dang wrote:
| Recent and related:
|
| _Web components will outlive JavaScript frameworks_ -
| https://news.ycombinator.com/item?id=38012662 - Oct 2023 (244
| comments)
___________________________________________________________________
(page generated 2023-11-27 23:01 UTC)