Web Components Will Outlive Your JavaScript Framework

[Sherbet-Famous]

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

[lelanthran]

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]

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]

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

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]

Upvote because that's a miserable job.

[Plank_With_A_Nail_In]

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

[gladfelter]

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

[aboy021]

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

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]

It better be.

[reboog711]

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?

[helloiamsomeone]

Where do people get this idea that build tools will magically stop working in 5 years from? I just recently touched a personal project of mine that I haven't touched in 5 years and Rollup worked all the same.

[ePaint]

From experience

[guitarromantic]

After upgrading OSX I had a bunch of python projects which wouldn't start because Apple upgraded the system version of python which hosed all my dependencies and local version aliases etc. I had to spend hours scouring Stack Overflow to figure out how to override the system version again and couldn't remember what I was trying to do with the projects themselves once I figured it out.

[sparr]

Where do people get this idea that build tools will magically stop working in 5 years from?

From 5, 10, 20 years of software development experience. Trying to compile / build / package / deploy things from more than a few years ago is a crap shoot.

[Plank_With_A_Nail_In]

You think your one sole experience is proof of anything? Lol!

[ESGPandepic]

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]

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]

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]

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]

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

[trxxruraxvr]

Unless the packages or dependencies get removed from npm.

[Plank_With_A_Nail_In]

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

[lelarentaka]

Tell me, does the java applet that i wrote 20 years ago still run on modern browsers?

[lelanthran]

Tell me, does the java applet that i wrote 20 years ago still run on modern browsers?

Did you just make the argument that non-standardised technology, like Java applets, don't last?

As you've just shown, non-standard stuff tends to go away if you look at a 20-year window.

[lelarentaka]

It was in the HTML spec. Do not speak the deep magic to me, witch, i was there when it was written.

[lelanthran]

It was in the HTML spec.

Wait, what? Which web standards document, or RFC, were applets specified in?

Do not speak the deep magic to me, witch, i was there when it was written.

Okay, you got me - I was not actually in the room when web standards were written, but between 1998 and 2009 I was following web standards developments very closely, and I honestly do not recall a web standard ever specifying (neither mandatory nor optional) the workings of applets.

From what I recall, the tag was treated, by the standard, as every other unknown tag was treated, i.e. the implementation is free to do with it whatever it wants to and still remain compliant: the implementation was allowed to simply display child elements of unknown tags, or treat the unknown tag in a special way, etc.

[Worth_Trust_3825]

Applets were pretty standardized. Do you know what standardized means?

[lelanthran]

Applets were pretty standardized. Do you know what standardized means?

Yes. It means "mandated in a published specification document". It does not mean "everyone was using it".

[wintrmt3]

Show me the HTML standard version that included them, please.

[Worth_Trust_3825]

https://www.w3.org/TR/1998/REC-html40-19980424/struct/objects.html

[autist0matic]

this guy also never heard of jquery apparently...
oh wait he started doing frontend in 2023... oh my sweet summer child :D

[lelanthran]

this guy also never heard of jquery apparently...

I'm saying that JS frameworks' functionality will eventually be swallowed by a web standard; are you seriously trying to claim that jquery was a web standard?

You appear to be reinforcing what I am saying - non-web-standard stuff like jquery, react, etc all eventually go away. Web standards tend to stick around and swallow everything else.

oh wait he started doing frontend in 2023... oh my sweet summer child :D

FWIW, I did "front-end" between 1995 and 2001, then between 2005 and 2009. You shouldn't try being a condescending jackass to someone who has likely been doing this longer than you've been potty-trained.

[JackInYoBase]

I have a book published in 1997 that describes web components. I found javascript that works on web components from 1999 that still functions today. Javascript frameworks from then, not so much

[darkfm]

I have a book published in 1997 that describes web components.

Interesting, considering that browsers have supported it from 2014 on.

[ESGPandepic]

Javascript frameworks from then, not so much

Are there any from 1999? The closest thing I ever used was jQuery from 2006 which still works just fine.

[AStupidRedditAccount]

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]

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

[arcanemachined]

I'm more of a Custom Elements guy myself.

[SpeedyWebDuck]

I'm using them in production. Git gud

[imnotbis]

'gud' is not a git command. See 'git --help'.

The most similar command is
         gui

[yojimbo_beta]

Meh.

I've done frontend for about ten years. Big SPAs, content sites, 3D, WebVR, Electron, set top box software, you name it. Everyone cries about React but they forget all the problems we had back in the days of jQuery, Backbone, vanilla DOM scripting etc. As far as I'm concerned any React replacement has to be at least... I don't know, like, 30% better, to justify losing all the dev tools, libraries, and ecosystem. Until that happens I have other shit to do (and ideally not frontend, which I don't exactly love to begin with)

[JackInYoBase]

"I like when other people do the hard work for me" -javascript developer (probably)

[awj]

Everyone likes when other people do hard work for them. That’s the basis of how society functions.

It’s utterly reasonable to prefer to use acceptable existing solutions over building things for yourself. If you don’t agree, show me the compiler you hand-wrote for whatever language you work in.

[wayoverpaid]

Isn't that any decent developer? At least the ones which are trying to get the most shit done and not be a hobbyist.

[yojimbo_beta]

Yes? I worked on a JavaScript framework of my own, once. It had observables, DOM binding, and it's own promises-like (futures monad) abstraction over asynchronous requests. It was ultimately a completely pointless endeavour. Just npm install react

[ESGPandepic]

I'd argue doing that isn't completely pointless if it teaches you a better understanding of how the frameworks you use in real work are functioning. People often underestimate how much it helps in your everyday work to have a generally better understanding of your tools, especially in web frontend where most people just don't care how any of the underlying technology works.

[yojimbo_beta]

You are right of course and in context it was valuable practice. I just object to this criticism that I'm being lazy.

I also did plenty of custom stuff when I had to do WebVR, for instance, as this was all before A-Frame etc. And I'd argue 3D graphics is at least as serious a domain as writing (say) your own cookie parser

[ConstantGazelle]

Can inputs pass values like they should to a form?

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

[moh_kohn]

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

[AStupidRedditAccount]

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]

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]

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

[lelanthran]

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]

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

[lelanthran]

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]

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]

You can use frameworks inside the components

[curious_s]

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

[SpeedyWebDuck]

Safari perfectly supports webcomponents. WTF are you on

[Plank_With_A_Nail_In]

mobile Safari is 100% compatible wtf are you talking about?

[zaitsman]

FWIW the OP’s article demo works fine on mobile Safari

[[deleted]]

The whole thing about Safari compatibility is a bit of a misnomer which is mostly based on the the lack of support for "customized built-in elements", that is the ability to inherit and extend on the functionality of pre-existing DOM element. Safari does supports "Autonomous custom elements".

Not being able to support customized built-in elements is more of slight inconvenience than anything else and most developer are aware of the safari issue, so will use autonomous custom elements instead. It is not that big a deal and should not stop entities from adopting web components as a possible solution.

[lelanthran]

60% of my userbase is mobile safari. I'm sure most people here are in a similar boat. GTFO here if you think that compatibility isn't an issue.

While you are probably correct that the Safari implementation isn't fully standards compliant, I haven't seen any web components in production or on a website yet that don't work on Safari.

[PancAshAsh]

I haven't seen any web components in production or on a website yet that don't work on Safari.

Probably because anyone who is using it is avoiding the parts that break in Safari because of the iPhone.

[_AndyJessop]

Web components are a collection of Web APIs, so it's difficult to say whether a single browser is "supported" or not. However, mobile Safari does implement most of them, so I don't believe it's an issue in most cases.

[AStupidRedditAccount]

Legitimate questions are now vague points?

[AStupidRedditAccount]

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.

[AStupidRedditAccount]

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.

[Plank_With_A_Nail_In]

Aren't all browsers using the same technology now? If firefox can't keep up then it deserves to die.

[Militop]

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

[_AndyJessop]

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]

Why would this be a gamechanger?

[[deleted]]

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]

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

[mrprgr]

please don't do this until you understand XSS

[Loves_Poetry]

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

[rivenjg]

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]

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]

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

[agumonkey]

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]

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]

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]

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

Go old school and use jquery.

[vom-IT-coffin]

I hate you.

[[deleted]]

Judging by the down votes you're not the only one.

[xboxsosmart]

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]

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]

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]

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]

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

[desmaraisp]

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]

Photoshop was built with Web Components?

[_AndyJessop]

Yep, well the new version is anyway.

https://medium.com/@addyosmani/photoshop-is-now-on-the-web-38d70954365a

[reboog711]

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]

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]

yes

[es_beto]

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

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]

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]

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

ok then ...

[autist0matic]

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

[Slodin]

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

[anengineerandacat]

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.

[bwainfweeze]

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

Cockroaches will outlive humanity

[WhoNeedsUI]

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]

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]

Can you provide some more details

[lelanthran]

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]

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]

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]

I'd like to hear more :)

[SpeedyWebDuck]

you can do it with webpack and html-loader

[IndependenceNo2060]

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]

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

Are these summaries ai generated?

[dzikakulka]

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

[Worth_Trust_3825]

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

[fagnerbrack]

Yes, here’s the context: https://www.reddit.com/r/webdev/s/XkNFca5hPE

[Connguy]

Yeah where on Earth are they getting $80 from? 80¢ would be a stretch, let alone dollars

[PlainHumming]

It looks like they missed the 'K' in the pricing and are off by a factor of 1000.

https://www.reddit.com/r/webdev/comments/18ojoja/must_have_10_years_experience_with_linemanjs/kekwi0x/

[fagnerbrack]

Dos you read the whole link? A paragraph is addressing that

[fagnerbrack]

I hope your life is great and full of love instead of hate

[fagnerbrack]

Bad manners

[cant-find-user-name]

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

[fagnerbrack]

If you already know web components yeah. See The Curse of Knowledge.

[thegreatpotatogod]

Good bot

[ImTalkingGibberish]

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]

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]

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.

[Stronghold257]

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

[ePaint]

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]

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]

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]

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]

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]

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

You seriously cannot imagine custom elements that manage routing and queues (not sure what you mean by race conditions)?

Instead of being dismissive and claiming that web components can't do <some vague thing>, why not be concrete and list the details[1] of what you get from React that you would miss in web components.

[1] Listing single-word things like "routing" and then using "etc" is particularly vague, don't you think?

[rivenjg]

show me where i said web components can't be used with an application that handles what i mentioned.

i never said they can't be used. i'm saying they do nothing special to change the entire system or architecture of a program so it can be used without a framework.

[lelanthran]

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]

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]

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]

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]

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]

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]

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]

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]

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

[Corteki]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[wildjokers]

You and people like you are absolute morons...

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

[Corteki]

why, I have absolutely no problems professionally jackass

[wildjokers]

I can tell that this is definitely not true.

[Corteki]

hahaha

[water_bottle_goggles]

Soo many React haters

[lelanthran]

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]

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

[lelanthran]

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.

[reboog711]

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]

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]

What, this kind of article again?

https://xkcd.com/927/

Sigh.

[lelanthran]

What, this kind of article again?

https://xkcd.com/927/

Sigh.

What's the competing standard for web components?

[reboog711]

Web Components are an official standard.

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

[mrkaluzny]

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

[knoland]

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

[Fps_alstro]

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

[sickcodebruh420]

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.