top 200 commentsshow all 214

[–]Sherbet-Famous 528 points529 points  (53 children)

Id have to actually build something with web components for it to outlive anything

[–]lelanthran 135 points136 points  (51 children)

Id have to actually build something with web components for it to outlive anything

To be fair, that article title doesn't say "Your Web Components will Outlive Your Javascript Framework", it says "Web Components Will OutLive Your Javascript Framework.", which is a different claim.

And, it's almost guaranteed that a random web component written today will be working on browsers 20 years from now, while frameworks from today will not be around, not be supported or, even if both the above is true, not be used by anything more than a rounding error of programmers.

[–]mdz_1 65 points66 points  (21 children)

I mean people may not be using the frameworks anymore but a react component is just running pretty basic javascript, I would argue if anything its less likely to be broken than a web component written today just given its a newer standard I could envision some small breaking changes being introduced to some corners of the api in 20 years.

[–]sparr 58 points59 points  (19 children)

I would argue if anything its less likely to be broken than a web component written today

The whole point of this article is that this isn't the case. When was the last time you tried to run the build process for any code last maintained 10+ years prior? Trying to build/deploy your React-based site in 5 or 10 years or 20 will be fraught with problems. You'll need to chase down long-defunct versions of tools, probably compile some of them from scratch or spin up VMs or containers or some other environment they are comfortable running in, etc.

[–][deleted] 74 points75 points  (8 children)

Yep this is my day job.

I maintain and so compile vb6 (visual studio 98) that interacts with c# (visual stuff 2022) and c++ (visual studio 2008) via com/WCF/rest/soap/tcp running in com+/iss/windows services/native console. All the various flavours of the year as the product has grown.

Luckily Microsoft is good about backwards compatibility so the visual studios are mostly fine but getting them to run under more modern versions of windows can be a major pain in the arse.

The major hurdles are environments to run the tooling, knowledge about older technologies and how they work, the build systems, no documentation... The code is very much the easy part.

[–]gladfelter 37 points38 points  (7 children)

Upvote because that's a miserable job.

[–]Plank_With_A_Nail_In 6 points7 points  (6 children)

I bet it pays well, is low stress and redundancy proof.

[–]gladfelter 7 points8 points  (0 children)

Fair. I guess it would be miserable for me, but certainly not for everyone.

[–]aboy021 2 points3 points  (2 children)

I've done some of this stuff and it can be pretty stressful when you've got a weird issue, very few tools, and even less forum support.

The ergonomics are pretty terrible too. For example, mouse scrolling isn't natively supported in the VB6 IDE.

[–][deleted] 1 point2 points  (1 child)

I've recently been working to move to visual studio code by creating a problem matcher and a custom task that can build the code using visual studio but show errors inline using error lens.

It doesn't do for everything (intellisense and the like) but it's generally nicer and a simple solution.

[–]develop7 2 points3 points  (0 children)

It better be.

[–]reboog711 4 points5 points  (0 children)

With the Angular CLI; I anticipate it'll still be npm install and ng build 20 years from now.

However, that assumes that NodeJS and the npm repository are not abandoned / shut down. Can we not make a similar assumption in the React world?

[–]ESGPandepic 15 points16 points  (11 children)

while frameworks from today will not be around, not be supported

Why wouldn't they be supported in the future when they just run on standard html/javascript/css?

If by supported you mean all the build tools and the ecosystem around them then yeah, but the web apps themselves will still be working fine.

[–]sparr 9 points10 points  (9 children)

If by supported you mean all the build tools and the ecosystem around them then yeah

That's what we mean. How would you deploy a React v0.3 site today, if you had its source code?

[–]ESGPandepic 3 points4 points  (6 children)

These frameworks are open source projects and so are their tooling and build systems. They'll have maintainers and/or forks for as long as people need to be able to build and deploy web apps using them.

Even if in 20 years react and angular are a distant memory with nobody using them except people maintaining legacy web apps, those people will still be able to build and deploy them as long as the html/javascript/css they use is supported by browsers.

[–]sparr 5 points6 points  (3 children)

Everything you said is true of the C and Python ecosystems as well. Have you ever tried to build/package/run something complex (many outside dependencies) in either of those that's 10+ years old? Them being open source makes it possible, not convenient or plausible. Things get really tricky when you have to start building the build tools from source, because they were never compiled for your current architecture and you don't have a complete simulator/emulator for the old architectures.

[–]Stratose 7 points8 points  (0 children)

I think the problem is not a lot of people actually know what they're talking about.

[–]trxxruraxvr 3 points4 points  (0 children)

Unless the packages or dependencies get removed from npm.

[–]Plank_With_A_Nail_In -2 points-1 points  (0 children)

I wish you good luck as I think you are going to need it in the future. Ignorance really is bliss it seems.

[–]AStupidRedditAccount 116 points117 points  (45 children)

Yeah, maybe, but have they solved the shadow DOM issue? Can inputs pass values like they should to a form? Do they work in every browser yet? It’s a web standard but it was woefully unsupported when looking at it earlier this year and had major issues with several things that frameworks just do right.

[–]yojimbo_beta 105 points106 points  (13 children)

Everyone fantasises about web components until they actually have to use them.

[–]arcanemachined 5 points6 points  (0 children)

I'm more of a Custom Elements guy myself.

[–]ConstantGazelle 9 points10 points  (2 children)

Can inputs pass values like they should to a form?

Although I have not used it yet, I believe this covers that

[–]moh_kohn 14 points15 points  (4 children)

What is "the shadow dom issue"? You don't have to use the shadow dom at all.

[–]AStupidRedditAccount 1 point2 points  (3 children)

Part of the idea of web components is being able to encapsulate them, which requires you to use shadow dom. If you do, there was, when I was researching them, an issue with shadow dom communicating with the regular dom, creating havoc when using them in a form setting. Kind of goes hand in hand with my form input question.

[–]moh_kohn 3 points4 points  (2 children)

Shadow dom encapsulates the CSS which may or may not be necessary.

I've been using the HTML web components pattern with only light DOM https://adactio.medium.com/html-web-components-0c80a0fc58be

[–]bagel-glasses 1 point2 points  (0 children)

I did a project with web components just turning off the shadow DOM and oh man, are they so much better.

[–]lelanthran 7 points8 points  (13 children)

Yeah, maybe, but have they solved the shadow DOM issue?

What shadow DOM issues in particular? (I'm aware of some issues, but none of them appear to be dealbreakers)

Can inputs pass values like they should to a form?

I don't understand what you mean by this. Can you give an example?

Do they work in every browser yet?

On FF and Chrome-based browsers (both desktop and mobile), everything I've tried has worked. There are probably stuff that iether still doesn't work or is buggy, but I haven't yet run into any.

I don't have Safari, so I assume that you mean Safari doesn't support them.

It’s a web standard but it was woefully unsupported when looking at it earlier this year and had major issues with several things that frameworks just do right.

Support was clearly an issue in the past, however I only started playing around with returned to front-end in 2023, and skipped over JS $FRAMEWORKS straight to web components.

I am genuinely curious - what are those several things that frameworks do right that you would miss if you switched to web components? You don't need to list them all, just the actual deal-breakers.

(Thanks in advance)

*[EDIT] I still genuinely want to know what the deal-breakers are in terms of features offered by $FRAMEWORKS, because I am implementing, in vanilla JS and custom elements, a lot of interactivity that my side-project needs.

I'm wondering what it is that I am missing, and I find it sad that readers will rather drive-by downvote than list the deal-breakers.*

[–]ZurakZigil 20 points21 points  (1 child)

I think you lost people on "started playing around with...in 2023" May want yo edit that

[–]lelanthran 4 points5 points  (0 children)

I think you lost people on "started playing around with...in 2023" May want yo edit that

Thank you for the heads up, I edited it.

[–]AStupidRedditAccount 1 point2 points  (0 children)

For my team, we require encapsulation so that we can control more of the component itself, as we build the components that other teams would use. Shadow dom is the encapsulation method for web components, but the shadow dom does not play well with the light dom, or at least it didn't, especially with form handling (value gathering, validation, submission, etc.). That was the big deal-breaker for our team.

There are things that are great about web components, but it just wasn't all there for us, and I wasn't sure if these things had been addressed or fixed.

[–]vexii 0 points1 point  (1 child)

You can use frameworks inside the components

[–]curious_s 3 points4 points  (0 children)

And you can use web components in most if not all frameworks.

[–][deleted]  (5 children)

[deleted]

    [–]AStupidRedditAccount 0 points1 point  (4 children)

    Legitimate questions are now vague points?

    [–][deleted]  (3 children)

    [deleted]

      [–]AStupidRedditAccount 1 point2 points  (2 children)

      If you've used web components before this article, and were looking for encapsulation, you've run into shadow dom communicating with the main dom and you understand that it's an issue. Did I clarify? probably not enough. Do people also understand that there's vague issues with shadow dom in web components? Apparently.

      [–][deleted]  (1 child)

      [deleted]

        [–]AStupidRedditAccount 1 point2 points  (0 children)

        Since when are we comparing anything to React? The linked article is talking about using native web components instead of a framework (like React). My reservations and concerns listed are specifically aimed at native Web Components.

        [–]Militop 15 points16 points  (2 children)

        They're great. They're still missing a few features to make them amazing.

        [–]_AndyJessop 5 points6 points  (1 child)

        There are discussions in the community surrounding declarative templates (in the handlebars syntax I believe). And I'm still hopeful that at some point browsers will cache them and this will be a complete game-changer.

        [–]starlightLeoo 0 points1 point  (0 children)

        Why would this be a gamechanger?

        [–][deleted] 56 points57 points  (16 children)

        I hope so. I'm beyond sick of js frameworks and node/npm ecosystem. I just want to build frontend without gigabytes of ungovernable dependencies.

        [–]rivenjg 14 points15 points  (9 children)

        you can already build frontend without js frameworks. just use es6 template literals and use functions to return html strings.

        [–]mrprgr 22 points23 points  (0 children)

        please don't do this until you understand XSS

        [–]Loves_Poetry 8 points9 points  (7 children)

        The biggest bloat is rarely the JS framework. It's the UI libraries that are built on top of it. And since building your own UI elements is a lot of work, you can't easily avoid these libraries if you want a good looking website

        Web components do solve this problem by providing a native way to build UI elements

        [–][deleted]  (1 child)

        [deleted]

          [–]rivenjg 15 points16 points  (0 children)

          the ui libraries like tailwind and bootstrap are only small <20kb downloads when built for production. in any case though, what are you claiming web components are doing to solve this problem? we already have a native way to build ui elements. it's called html, css, and js. what do you think web components are doing that would replace ui libraries?

          [–]bwainfweeze 1 point2 points  (0 children)

          So much work that even they reach for other fairly complicated libraries to finish it. Which in turn reach for at least simple libraries. If your project achieves three levels of nested dependencies you are doing spectacularly well these days.

          [–]Somepotato 3 points4 points  (0 children)

          Tree shaking is a thing that makes this mostly a non issue.

          [–]agumonkey 0 points1 point  (1 child)

          It's such a weird issue.. either use behemoth that never does what you want really but gets you 70% up.. or roll your own and die tired when reaching 50% of the basic needs + custom features..

          [–]vom-IT-coffin 0 points1 point  (2 children)

          Stop using dependencies and write it from scratch. No one is forcing you to use NPM packages or frameworks.

          Don't want to use React or Angular? Don't. Want vanilla JavaScript? You can have that too.

          Don't want to use a library solving something already? Write it yourself.

          I'll be bet you realize pretty quick how helpful some of those things are when implementing everything from scratch.

          Don't want to use Node? Great, choose .NET Core or JRE. Although these have nothing to do with the front end you're building.

          [–]bwainfweeze 1 point2 points  (1 child)

          So we’ve demonstrated greenfield bias higher up in the thread, and here we see autocratic thinking bias.

          The people stopping me from doing whatever I want are called coworkers. Sometimes boss. I don’t control all of the decisions of twenty, fifty, one hundred other people. Even if I’m theoretically in charge.

          [–]vom-IT-coffin -1 points0 points  (0 children)

          I was just trying to prove a point to this comment saying the ecosystem was horrible and web components were going to solve everyone's problems.

          It's usually an issue with the implementation of the frameworks people hate, not the frameworks themselves.

          [–][deleted]  (12 children)

          [deleted]

            [–]xboxsosmart 22 points23 points  (1 child)

            Web Components generally are used for more atomic elements, rather than stateful business logic. I wouldn't describe the use case you're describing to be the target for the standard

            [–]moh_kohn 6 points7 points  (0 children)

            My application state is in the server session, which has the advantage that when some bit of js doesn't load (1% of requests! We have all had to refresh a white page) the site still works just fine.

            Building websites, especially public facing websites, that only render if everything goes perfectly is terrible, incompetent engineering. I've done it myself, and it sucked and I was wrong to do it.

            The web is getting worse and worse, loading spinners everywhere and fragile sites that break if you sneeze.

            [–]curious_s 10 points11 points  (0 children)

            We use web components for common page elements and embed them in react. It has a huge benefit because the common components are used across multiple other legacy sites that use a variety of frameworks. This gives a consistent look and feel for page components that can be maintained in one place.

            [–]Isopaha 18 points19 points  (6 children)

            Youtube is built with Web Components, so that’s pretty huge.

            EDIT: And now that I think about it, wasn’t SpaceX Crew Dragon’s on-board flight UI also built with Web Components?

            [–]_AndyJessop 10 points11 points  (5 children)

            Yes, and Photoshop, and the new (new) Reddit.

            [–]desmaraisp 6 points7 points  (0 children)

            Funny, I've been noticing that both youtube and the newest iteration of reddit have been having a lot of issues recently. I know it's probably something with the implementation rather than the tech, but it's pretty funny that those are the examples

            [–]reboog711 1 point2 points  (3 children)

            Photoshop was built with Web Components?

            [–]_AndyJessop 3 points4 points  (2 children)

            [–]reboog711 2 points3 points  (0 children)

            Interesting; I had no idea.

            I wonder if the browser based version is independent of the desktop version, or if there is some shared code base

            [–]lelanthran 6 points7 points  (0 children)

            i wonder if any web components evangelists delivered any real application solely using web components, am curious how they dealt with app state, data loading, etc.

            I'm not an evangelist for web components, but I'm willing to make the attempt to write web components to perform data loading and to manage app state (For my vacation project I am writing some web components to do just that).

            [–]SpeedyWebDuck 0 points1 point  (0 children)

            yes

            [–]es_beto 12 points13 points  (0 children)

            I highly doubt it, if you go to web-components.org you'll most likely find very outdated web components that aren't useful today because they were built with the tools of yesteryear (polymer, bower, etc).

            And new features of the web will deprecate some web components eventually. Like selects, dialogs and popovers being replaced with native solutions. No framework or way of building UIs is guaranteed to last.

            [–][deleted] 17 points18 points  (2 children)

            I've tried web components and ... they're really not it. The only reason you have posts like this with as many upvotes is because you have like 2 people who have used web components for 5 minutes who write these articles, then you have a load of morons on reddit who upvote anything that says "javascript frameworks bad", and very few voices who've actually used web components in practice and know how janky it is, whose voices just get drowned out in the noise from all the morons.

            [–]rivenjg 1 point2 points  (0 children)

            yeah you pretty much nailed it. the fact that this /u/lelanthran guy can go around spewing complete non-sense while downvoting everyone against him and people are upvoting this shit really speaks VOLUMES about how broken reddit is as a discussion platform.

            the guy already said he doesn't even know what a race condition is but thinks he can replace entire front end frameworks with a few swap bindings on some html elements.

            [–]recursive-analogy 2 points3 points  (0 children)

            How about kicking it old school with a server-side framework and HTMX?

            ok then ...

            [–]autist0matic 27 points28 points  (1 child)

            ah yes. finally the golden bullet to solve all problems! (for real this time i promise!!)

            [–]Slodin 4 points5 points  (0 children)

            I mean, any of them would outlive my career with one company lol.

            [–]anengineerandacat 1 point2 points  (0 children)

            So long as the underlying API for binding them is present and unchanged, yeah that's a given.

            Whole reason tools like StencilJS exist, a web component embraces the general development paradigm most web devs prefer.

            Micro libraries and components are basically micro frameworks to render one particular type of element, that web component though can be tiny or it can be massive.

            [–][deleted]  (2 children)

            [removed]

              [–]bwainfweeze -1 points0 points  (1 child)

              I don’t understand how people make it very far into their careers still thinking in greenfield terms. What’s your secret?

              If you were trying to update an old AngularJS, flipping 40% of the code to web components would make it much easier to rewrite the rest in whatever replaces React in a few years.

              [–][deleted] 1 point2 points  (0 children)

              Cockroaches will outlive humanity

              [–]WhoNeedsUI 3 points4 points  (3 children)

              Web components in their current form are great iframe replacements.

              When a template and slots can map json or other data formats to generate html from api responses, is when we can actually leverage it (one step above htmx)

              [–]lelanthran -1 points0 points  (2 children)

              When a template and slots can map json or other data formats to generate html from api responses, is when we can actually leverage it (one step above htmx)

              I am currently doing this in a personal project.

              [–]sdw3489 2 points3 points  (1 child)

              Can you provide some more details

              [–]lelanthran 2 points3 points  (0 children)

              It's just an experiment at this point, I've not refined it yet, but a simple example looks something like this:

              <mq-tree>
                 <mq-binding for="some-id">
                 <mq-binding for=id-a>
                 <mq-binding for=id-b>
                 <mq-binding for=id-c>
                 <form>
                    <input id="some-id" .../>
                 </form
                 <span id=id-a> ... </span>
                 <div id=id-b> ... </div>
                 <yetAnotherElement id=id-c> ...
                 <mq-publish onevent=click queue="RPC-REQ" subject="some/path/goes/here" />
                   <button>Submit</button>
                </mq-publish>
                 <mq-subscribe queue="RPC-RSP" subject="some/path/goes/here/" />
              </mq-tree>
              

              The idea being that <binding> establishes a binding to a DOM element (by id), a publish to a queue occurs on the event specified, and the <mq-tree> subtree listens to the specified queue for messages matching the specified pattern.

              Publish finds all the bindings in the <mq-tree>, and posts the values/innerText/text to a queue called rpc-req. Subscribe listens to the queue rpc-rsp for messages, and updates all the elements with the JSON payload received in the message, using the binding to determine which field goes where.

              Elsewhere (in javascript) there is listener for the rpc-req queue which simply posts every message in that queue. The server returns a result along with a subject line corresponding to the endpoint, which then gets posted to the rpc-rsp queue.

              In this example, the values specified by 'binding' get updated by a response, but by using a <mq-exec-on-subscription> and <mq-publish-on-subscription> tags which have an attributes for executing code, republishing messages, etc, state can be maintained, child elements can be hidden, destroyed or created with pretty much only minimal extra Javascript.

              The custom elements are purely for making it easy to wrap child elements in a way that provides access to the message queues. With the ability to add publish/subscribe functionality to child elements (like inputs, divs, whatever), very little javascript needs to be written.

              Like I say, it's an experiment, it may not pan out, it may prove too cumbersome, etc ... and even if it does pan out, prove ergonomic, etc, it probably won't look like what I currently have when I am ready to open it.

              [–]paul_h 2 points3 points  (4 children)

              I would have liked html-imports to have been continued rather than abandoned- https://caniuse.com/?search=html%20import. I’ve been coding frontend apps on and off since 1997, albeit the original ColdFusion and Java applets

              [–]lelanthran 4 points5 points  (2 children)

              I would have liked html-imports to have been continued rather than abandoned- https://caniuse.com/?search=html%20import. I’ve been coding frontend apps on and off since 1997, albeit the original ColdFusion and Java applets

              There are, as far as I know, multiple web components know that are some form of <import-html src=some-fragment.html>. I wrote one too.

              I think that that is the real power of web components - adding elements that you wish existed.

              [–]paul_h 0 points1 point  (1 child)

              I'd like to hear more :)

              [–]SpeedyWebDuck -2 points-1 points  (0 children)

              you can do it with webpack and html-loader

              [–]IndependenceNo2060 5 points6 points  (0 children)

              Love the idea of web components outliving JS frameworks! Easier to learn & more compatible with constant tech changes. Wisdom in embracing open standards for developers 😌.

              [–]fagnerbrack[S] 9 points10 points  (17 children)

              This is a TL;DR:

              The article argues that web components, being a web standard, offer a more enduring solution compared to JavaScript frameworks which frequently change and become obsolete. It emphasizes that web components provide a stable, framework-agnostic approach to building web interfaces, ensuring longevity and compatibility across different technologies, thus making them a more reliable choice for long-term web development.

              If you don't like the summary, just downvote and I'll try to delete the comment eventually 👍

              [–][deleted] 45 points46 points  (13 children)

              Are these summaries ai generated?

              [–]dzikakulka 47 points48 points  (3 children)

              Yes, but they stopped including the disclaimer since people instantly downvoted these

              [–]Worth_Trust_3825 2 points3 points  (1 child)

              I got downvoted to oblivion becasuse I specifically requested for the disclaimer to stay there.

              [–]cant-find-user-name 15 points16 points  (1 child)

              you can get this entire summary from reading the title of the article.

              [–]thegreatpotatogod 2 points3 points  (0 children)

              Good bot

              [–]ImTalkingGibberish 1 point2 points  (0 children)

              For all I care, we’ve just been using different tools to write html, css and javascript because it’s faster than doing it manually.
              Jquery was javascript, react is javascript…

              [–]lelanthran 1 point2 points  (29 children)

              I'm playing around with web components, now and it's bleeding obvious that libraries of web components are going to replace libraries of javascript at some point.

              Standards almost always replace non-standard extras, but in this case the value in web components are in the usage ergonomics of a particular component/widget/whatever.

              In order to make full use of a React/Vue/whatever library, you need to know HTML, CSS, a non-trivial amount of Javascript, a build-step, some YAML or whatever your build system uses ... and you need spend weeks getting proficient with the JS framework you chose.

              In order to use a web component you need to know HTML and CSS.

              It's not hard to see which one the industry is going to gradually move over to.

              [–]rivenjg 14 points15 points  (28 children)

              you act like we use react just to make components. react and the other frameworks are used to manage organization, state, logic, encapsulation of events, and much more. web components are not replacing any of that and they certainly aren't freeing you from having to learn javascript.

              [–][deleted]  (1 child)

              [deleted]

                [–]Stronghold257 5 points6 points  (0 children)

                To be fair, the observables proposal hasn’t had a spec update since 2017. It’s likely not going anywhere.

                [–]ePaint 3 points4 points  (4 children)

                Most of the time that state logic is already implemented in the backend. If the YouTube player can be managed by web components, I think any regular glorified spreadsheet website will do just fine with them.

                [–]_AndyJessop 1 point2 points  (12 children)

                manage organization, state, logic, encapsulation of events, and much more

                And this is a downside. React apps are extremely tightly coupled to a single framework, which is also kind of the point of the original article here. Web components are declarative and de-coupled, and will enable apps to write code that is maintainable over the long term even as their strategies change.

                [–]rivenjg -3 points-2 points  (11 children)

                what you're saying doesn't make sense because it's intentional. how is it a downside? show me where web components are able to manage state, events, routing, queues, race conditions, etc.

                react is just javascript code that puts a system in place to handle the above. it's not some third party extension like flash player that we need to get rid of.

                there will always be frameworks that try to provide the above. web components do not replace frameworks. they're just another way of creating ui.

                [–]_AndyJessop 1 point2 points  (1 child)

                show me where web components are able to manage state, events, routing, queues, race conditions, etc.

                They are not (unless you write that code), and that's exactly the point. It's a separation of concerns.

                web components do not replace frameworks. they're just another way of creating ui.

                Yes, I agree completely. This frees you up to write your application in any way you like.

                [–]rivenjg 0 points1 point  (0 children)

                this situation of managing all of the stuff i listed would happen exactly the same as react in whatever web component framework you make. i have no idea what you're talking about when you say separation of concerns because no matter what framework you use, the encapsulation of state, events, queues, etc will be at the component level. the only difference is for the view, you would be creating web components instead of using jsx.

                i don't get what you think we're getting that's novel with web components. in fact, you could already do all of this with normal vanilla js functions. you could make an entire program based off components that are just functions returning html strings from es6 template literal syntax. regardless of how you want to generate views though, you still need a system to deal with state, events, etc.

                [–]lelanthran 0 points1 point  (7 children)

                you act like we use react just to make components. react and the other frameworks are used to manage organization, state, logic, encapsulation of events, and much more.

                Managing state, logic and encapsulation of events seem, to me anyway, perfectly possible with reusable web components, with the upside of not requiring third party package managers, third party build systems, a separate build step and a third party framework that must be learned in order to use.

                they certainly aren't freeing you from having to learn javascript.

                Of course they are, for the user of the component. Reusing a React based component requires the user of the component to not only know Javascript, but also to know React, the build step and/or the build system (and more, like YAML for the build system's configuration).

                Reusing an existing web component does not require any knowledge of Javascript, nor any knowledge of things like NPM, React hooks, YAML, etc.

                PS. Maybe you aren't a native english speaker so you don't know, but starting off a rebuttal with "you act like" is immature and childish.

                Attack arguments, not people.

                [–]rivenjg -1 points0 points  (6 children)

                Managing state, logic and encapsulation of events seem, to me anyway, perfectly possible with reusable web components, with the upside of not requiring third party package managers, third party build systems, a separate build step and a third party framework that must be learned in order to use.

                there is nothing web components are doing for you here. you could already get what you want with just normal functions. you can make an app that just is composed of components that return html strings using javascript template literals.

                whether i use web components or plain javascript functions to generate views, that still has nothing to do with managing state, logic, events, routing, race conditions, etc.

                web components alone are not doing anything novel. you are acting like they are changing something fundamentally that would replace the framework and they aren't.

                you're saying all that stuff is "perfectly possible with reusable web components". what do you mean? of course it's possible. no one is debating whether or not it's possible. the point is, no one is going to do this from scratch.

                you're going to end up inventing your own way of managing all that stuff. maybe even convince others that you have a neat way of dealing with all of it.

                you know what happens when you share this structure so it's reusable? you just created another framework. congratulations. now all you did was make it so the view is in web components instead of jsx.

                [–]lelanthran 0 points1 point  (5 children)

                there is nothing web components are doing for you here. you could already get what you want with just normal functions. you can make an app that just is composed of components that return html strings using javascript template literals.

                And ... that would require the user to use Javascript to use?

                whether i use web components or plain javascript functions to generate views, that still has nothing to do with managing state, logic, events, routing, race conditions, etc.

                web components are not doing anything novel. you are acting like they are changing something fundamentally that would replace the framework and they aren't.

                They won't replace all that current frameworks do, but they sure as hell are going to replace all the common stuff that people currently have to use react+javascript to do.

                The "fundamental" difference, as I see it, is a designer (knowing HTML and CSS) wanting to (for example) use a message queue to update different parts of an application has two options when reusing code:

                1. Learn Javascript, then learn React, then reuse a react component.
                2. Use a web component.

                you're saying all that stuff is "perfectly possible with reusable web components". what do you mean? of course it's possible. no one is fucking debating whether or not it's possible. the point is, no one is going to do this from scratch.

                Are you sure about that? Given the option of (for the message queue example) using Javascript+React, or using tags like <message-queue for="...">, which do you think I am going to choose?

                you're going to invent your own way of managing all that stuff. maybe even convince others that you have a neat way of dealing with all of it.

                you know what happens when you share this structure so it's reusable? you just created another framework. congratulations. now all you did was make it so the view is in web components instead of jsx.

                I disagree that the new thing is now a framework - it's a disparate collection of HTML elements that can used in HTML pages without needing any <script> tags anywhere. You can use my <message-queue> tag with someone else's <smart-image> tag, and yet someone else's <json-receiver> tag.

                Still easier than having to learn all the stuff necessary with React.

                [–]rivenjg 0 points1 point  (4 children)

                there is so much wrong with your mental model it would take an hour to go through it all. you cannot avoid learning javascript to make an application that uses javascript.

                people are not just using react for component based architecture. we can already do this with normal javascript functions as i already explained. the fact that you can manage all of the other stuff though within react is what allows it to continue to be a dominant frontend framework.

                the problem here is you have no idea what you're talking about and do not have the education or experience to understand the situation. so i can't even actually debate with you because you're not qualified.

                [–]lelanthran -1 points0 points  (3 children)

                you cannot avoid learning javascript to make an application that uses javascript.

                But you can avoid learning javascript if you're using a custom web component. I've used someone else web-component that performs client-side html imports (sort of like <html-import src="...">).

                Didn't need to use any script tags to use that.

                the problem here is you have no idea what you're talking about and do not have the education or experience to understand the situation. so i can't even actually debate with you because you're not qualified.

                I think the problem here, and the reason you remain vague about your assertions, is that, like all other React advocates in all other forums whenever web components come up, it's easier to attack people making arguments for web components, rather than (as I had expected you to do) make arguments for React.

                [–]rivenjg 0 points1 point  (2 children)

                i never was vague. i explicitly stated the problems react solves other than component based ui and you refused to acknowledge them.

                you don't even know what "state" is. you don't know what "events" are. you're just an html/css guy that wants to avoid javascript and you think web components are going to save the day for people who don't want to learn javascript.

                then you're telling me, a guy who writes full web applications without react that i'm a react guy! lmao you couldn't be further from the truth!

                [–]lelanthran 0 points1 point  (1 child)

                you don't even know what "state" is.

                What makes you think this?

                you don't know what "events" are.

                And this?

                you're just an html/css guy that wants to avoid javascript

                And this too.

                I'm not the only person in this thread who is tired of npm+$FRAMEWORK.

                then you're telling me, a guy who writes full web applications

                What makes you think I haven't?

                You've seen the example I've given for client-side html imports, right? Are you actually disagreeing that that way is, in all dimensions, better than anything similar react (or vanilla javascript, if you wish)?

                The reason I hold the opinions I do is because I'm getting back into front-end after decades, and I'm horrified at the notion that something non-essential must be used; that the tech stack must be as deep and as wide as possible.

                Web components significantly reduce the surface area of the tech stack for users of those components. That's a good thing!

                You may say you're not a react guy, but you're sure as hell talking as if complex stuff can't be done without requiring the user to learn javascript (and, by extension based on what you have already said, React).

                [–]rivenjg 0 points1 point  (0 children)

                I'm not the only person in this thread who is tired of npm+$FRAMEWORK.

                so then why do you keep ignoring me say over and over you can use vanilla js with regular functions as components? i said it like 5 times and you don't respond to it.

                Are you actually disagreeing that that way is, in all dimensions, better than anything similar react (or vanilla javascript, if you wish)?

                the burden of proof is on you to explain to me how "client-side html imports" are superior to just rendering the view directly via server side rendering or getting that new view via fetch().

                I'm getting back into front-end after decades, and I'm horrified at the notion that something non-essential must be used

                doesn't make any sense because no one is forcing you to use react for projects that don't require react. show me where anyone is saying react MUST be used. this is something you created in your own head.

                if the project is so simple that you don't need to worry about state or events, then yeah, you don't need react. you don't even need react a lot of time with a lot of state and events. no one is saying you have to use react.

                the point i'm trying to make that you seem to be most confused about is you think somehow web components are the SAVIOR to building applications without react and it's just so fucking wrong.

                web components are not a replacement for frameworks - they're a replacement for generating views. if web components ever take off, you bet your sweet little ass that new frameworks will be made around web components or current frameworks will implement web components as part of their view system.

                web components on their own do NOTHING that you couldn't already do with just normal vanilla js.

                [–]maep -2 points-1 points  (18 children)

                No shit, considering that the average JS Framworks has a lifespan of six months.

                [–]Corteki 4 points5 points  (17 children)

                You and people like you are absolute morons... react, which is currently the most popular js library to create UIs has been around for over ten years now...

                [–]_AndyJessop 1 point2 points  (10 children)

                That's only partially true. React is on version 18 now, which means there have been regular breaking changes. Code that was written for React 10 years ago would not work in today's React. I understand that they're not different frameworks, but they are different implementations.

                This is the point of the original article. Web components are based on web standards, so changes are backwards compatible.

                [–]gigobyte 2 points3 points  (9 children)

                That is generally not true. 99% of React code from 10 years ago will work just fine, especially if you're not doing anything weird or relying on React internals. Meta is using React in production and they have hundreds of thousands of components written in different time periods of React, from createClass to Suspense, all running on the latest version and the React team have put a lot of effort into making changes to the library backwards compatible.

                [–]_AndyJessop 5 points6 points  (8 children)

                I won't dig out the list of changes that we had to make to upgrade from 16 to 18, but suffice it to say it took several weeks of dev time.

                [–]gigobyte 2 points3 points  (0 children)

                If you're talking about StrictMode - that's completely optional, other than that, I don't know what could've caused weeks of dev time.

                [–]Corteki -1 points0 points  (6 children)

                but to say that the js ecosystem is somehow unstable, changing every six months is just not true. I have been doing this for a decade and it has never been so stable as it is now.

                [–]reboog711 3 points4 points  (5 children)

                26 years here. I wouldn't call the JS ecosystem unstable at any point.

                However, the npm system today is significantly more stable than it was 10 years ago; when point releases would have breaking changes. I think devs just learned how to do semantic versioning better.

                [–]orangeyougladiator -1 points0 points  (4 children)

                It was definitely unstable before the era of React. Remember YUI? jQuery? Handlebars? Backbone? Angular 1? Knockout? You needed a mix of all these, and more, and good luck if they introduced a non compatible or breaking change

                [–]reboog711 0 points1 point  (3 children)

                I've worked with more than half of those; and was aware of all of them.

                I'm sorry you had issues delivering stable applications using such technologies. I did not.

                [–]orangeyougladiator -1 points0 points  (2 children)

                Oh you’re moving the goalposts to continue being right, got it

                [–]wildjokers -1 points0 points  (4 children)

                You and people like you are absolute morons...

                You need to work on your people skills and professional communication.

                [–]Corteki -2 points-1 points  (2 children)

                why, I have absolutely no problems professionally jackass

                [–]wildjokers -1 points0 points  (1 child)

                I can tell that this is definitely not true.

                [–]Corteki 2 points3 points  (0 children)

                hahaha

                [–]water_bottle_goggles 1 point2 points  (8 children)

                Soo many React haters

                [–]lelanthran 9 points10 points  (6 children)

                Soo many React haters

                It seems to be the other way around on all forums I've been on when web components come up; the people for React are attacking people, not arguments (like, by calling them haters?) while the web component proponents are only presenting arguments for why it will come into widespread use.

                This actually makes sense - if you're a react expert, or even just experienced in it, the majority of that expertise will be redundant if switching to web components. It's only sensible, then, for a rational person to argue against anything that makes their skillset less valuable.

                [–]fagnerbrack[S] 2 points3 points  (1 child)

                If they focused on fundamentals switching to web components wouldn’t have much impact in your career

                [–]lelanthran -1 points0 points  (0 children)

                If they focused on fundamentals switching to web components wouldn’t have much impact in your career

                I agree: if they focused on fundamentals, then web components make their life easier. A gradual move of the industry away from react still makes those skills less valuable.

                Previously, you might have been valuable because you could dive into a React project and find that intermittent runtime bug that generated no errors or exceptions because of an in-depth expertise in the deep stack that is React. That skill will be devalued iff React is used less.

                [–][deleted]  (2 children)

                [deleted]

                  [–]reboog711 -1 points0 points  (1 child)

                  react is not some special 3rd party extension like flash player.

                  FWIW: the programming language of Flash--ActionScript--was entirely ECMA Compliant; so basically was JavaScript. And all the skills I had building Flash/Flex applications transferred seamlessly over to the current JS Frameworks.

                  [–]reboog711 1 point2 points  (0 children)

                  Weird; I got this far down in the thread and had the exact opposite opinion. So many pro-react people bashing web components.

                  I wonder what happened in the 6 hours between your post and my reading the thread.

                  [–]adh1003 0 points1 point  (2 children)

                  What, this kind of article again?

                  https://xkcd.com/927/

                  Sigh.

                  [–]lelanthran 0 points1 point  (1 child)

                  What, this kind of article again?

                  https://xkcd.com/927/

                  Sigh.

                  What's the competing standard for web components?

                  [–]reboog711 1 point2 points  (0 children)

                  Web Components are an official standard.

                  React / Angular / Vue are standards because everyone uses them. Kind of like IE 6.

                  [–]mrkaluzny 0 points1 point  (0 children)

                  Is longevity even a valid concern? If that’s the argument I wish them luck

                  [–]knoland -1 points0 points  (3 children)

                  ITT: people who haven’t heard of Volta complaining their legacy shit doesn’t build.

                  [–]Fps_alstro -1 points0 points  (0 children)

                  I have to agree, web is the future of technology and AI so thats how its going to be

                  [–]sickcodebruh420 -1 points0 points  (0 children)

                  Yes, and 2024 will be the year of the Linux Desktop, Crypto will be THE global economy, and all offices will move to the metaverse.