By 2019 we all agree that components are the way to build fast, elegant and maintainable UI's. The problem is that every framework, like ReactJs, Angular(JS), VueJs, or some other smaller UI framework, uses its own patterns and solutions to common issues. These frameworks promote reusability and that they are easy to use. Also, one point I hear often is that they are mostly backed by big companies, like Google or Facebook. Let's have a discussion if this is really true, if maybe the community could do better and if there perhaps is a better alternative.
Web development is in a unique position. Web site, Web Applications, PWA's or whatever you want to call them are running in a browser, and in the end, it is all HTML, CSS, and Javascript ( and maybe Web Assembly). The goal then should be to use these tools most proficiently possible. I don't mean by that to use all of them without any kind of library or framework. You should use them, but what happens if we have too many to choose from? Overchoice happens! You are paralyzed because you have too much to chose from. Instead of being fast, you are slow because you don't know what frontend UI library to go with.
Okay, you now think: "I will go with reactjs every time.". This can be one solution. It can be a perfectly fine solution but still Angular, and the other UI frameworks still exist. This means that instead of working together as a community, we are fragmenting ourselves into these small communities. It gets even worse when you look that most of these tools are lacking features that we use daily. Routing in ReactJS is not fun at all. Form validation is also not fun and something nobody wants to do. So people need to create libs again for these UI frameworks, and there are most of the time like 2 or 3 libs to do these things. Not only we split our efforts into these groups of UI frameworks in these groups, but we also cut our efforts again to reinvent the wheel. Just think about the working hours we as a community have wasted here?
I can see people now think, but this is a good thing! Is it really? Please google: "Year of the Linux desktop.". Desktop Linux has the same problem. Gnome, KDE, XFCE, Cinnamon, Mate, LXDE, and man more. They all try to solve one thing: Make Linux better on the Desktop. Are they succeeding? You tell me down below in the comments.
Next point is reusability. Does someone remember the jump from Angular 1 to Angular 2? Yeah, it was like a completely different framework. Now we have Angular, and AngularJS which is not confusing at all. You now think, "but wait! Reactjs does not have breaking changes". You are right; they had no implicit changes like react v1 and react v2! I dare you to try to post react code where you are not using hooks! Half of the comments will be about "why are you not using hooks???". The same happened when you had to rewrite your react code from class-based components to function based components. Now I ask you a question where you have to be honest to your self and take down the "I'm a developer hat and want to use the new fancy shit" and put on the "I want to solve real problems and give people solutions they really need.". Did any of these changes really give any value to your customers? To your users? To your business? Is your code really now more comfortable to read? If you are really honest to yourself, then you would probably still be happy with class-based components. I think we can now say that maybe we have been tricked by marketing?
Wait, what? What has marketing to do with this? See people tend to forget. Who created ReactJS? Facebook, and who created AngularJS? Google. What are these companies known for? If you now say a social network and internet search then again you have the wrong hat on! They are known for advertising and marketing! If you want to know what a company is really doing is not to look at there products but how they make money.
The tail of "It is backed by a big company, so it has to be good.". I hear this so often without the person even having thought about it for longer than 1 second. This sentence promises that just because a company with a lot of money is behind the framework you are using will not go away one day. Google is famous for killing projects. There is even a website for this: https://killedbygoogle.com/. Still, want to use Angular? Okay but what about facebook? Facebook uses reactjs for a lot of projects. They are also looking for new enginers all the time and wouldn't it be efficient if the person joining your team would already know the framework lib you are using? This is something you have to decide for yourself.
I hope you now see some of the problems that we are having right now in the web development community.
How can we fix this? I personally think we already have the right way of fixing all of these problems. Standards! Yes, correct standards! The W3C is an excellent consortium, and more people from the community should be involved there. But this is a topic for another blog post.
Why do standards help us with all the issues?
When a technology becomes a standard, all major browser already have it implemented and ready to use. So this means that I, as a developer, don't need an extra library and I don't need to think about edge cases in a different browser. If there are bugs or problems, then it is in the responsibility to fix this bug for all its users. So it is in one hand to fix it not in thousands of developers hands. It would also help with the fragmentation of the community. What if you could write one component and use it in VueJS, Angular and ReactJS? Wouldn't that be fantastic? So more developer could work on one Calendar component and make it an excellent component instead of having 20 half bakes calendar components? What if all of this would happen without one big company backing this up? Instead, we as a community and all browser vendors?
What if all of this happened and we forgot?
Yes, we! The technology is called "Web Components v1".
Back in 2014, there was a big discussion if we as a community should go with web components or ReactJS. As you now know, we decided to got with ReactJS. At that point in time, it was maybe the right choice because web components were too young and the spec was not ready. That's why we call them web components v0 and we now have v1 since 2018. Now, all big players accepted this spec and have implemented it except edge (of course). Also, there are polyfills for older browsers.
So how do you use them, and how do you integrate them into your current projects?
We will discuss this next week since this blog post is already very long. See this one more as discussion and feel free to comment down below!
👋Say Hallo! Instagram | Twitter | LinkedIn | Medium | Twitch | YouTube
Top comments (248)
I'll be interested to see how you build apps with web components and no frameworks next week.
We've tried this at my company and its a total mess. We've found that using a framework with web components is a more sane solution. Otherwise you end up with this Frankenstein patchwork of libraries and proprietary code that zero devs of your hiring pool have experience with.
Okay maybe this is not clear from the post:
I'm not against frameworks! I'm against everybody doing its own thing!
Use frameworks like Polymer, stencil, and LitElement.
The goal should be to don't have these frameworks at all at some point.
The best framework is these that you don't feel you are using it.
I don't know if I'd put lit element in the same category as React. But I do see how they overlap.
We decided against Stencil because it doesn't allow you to extend other components. Lit element has obviously superseded Polymer. So the only real choice at this point is LitElement.
Writing an app only using LitElement presents a number of problems. How do you do routing? How do you do forms? To give two examples you gave in your article. We found ourselves rolling our own code or pulling in libraries. I mentioned this above... I'll wait for your next article to see how you solve these I guess.
I don't have this series planed very far.
The point I wanted to make there was:
Instead of having like 20 implementations of forms it would be nice to have 1 but a really good one! Maybe it does not exists now but if we would use web components for that at least i think that we would have a way better product at the end.
I get what you're saying. Part of the problem I think is that there is never one golden solution. There are always pros and cons. And even worse everyone has their own opinion about how things should work. Still I agree that web components are going to help cull the field of tech currently out there.
There are webcomponents that handle routing,you actually don't need a framework to build SPAs.
Web components that are widely adopted, have a strong community, and are production ready?
I never said it couldn't be done. I have an app in production that proves it can. But I'm not proud of what we did. I think there are better solutions.
There is not one gold solution and I'm not saying to ditch frameworks in general.
My point was that there should be one target.
Yes, this target right now is HTML but still, I can not easily take my reactjs component and put it into vue for example.
it's like jquery back in the day. everyone used it until it was just as easy to do it in vanilla JS. maybe this will be the case with frameworks as ES progresses.
I hope so :)
This would be amazing and great!
React is a library not a framework. vue too, if we're being real. Also web components aren't viable or reasonable at scale on their own. To say they are is a little stubborn. They're better with libraries, but then you're back at square 1
True, but at some point, we were at square 1 with these other libs too.
But with web components at least in the end we could target web components and use them everywhere without the need of having an extra framework.
Idk about routing in LitElement, but there's a library especially for doing routing in a micro front end environment github.com/kriasoft/universal-router
You mean to say only using standard HTML markup and OOJs
work_status: I'm looking for work!
I suggest you ACTUALLY learn React, Angular or even Vue
BTW give Chris Hawkes (Youtube) some credit.
Way to get some attention. Ditch React, then go on to create another library/framework.
I don't think his point was not to create another library/framework. Rather it is to develop the web components API present in the browser and making it rich enough so that no longer there needs to be 223452345 java-script frameworks and another one popping out as we are typing this. Please think selflessly, this is not twitter fight.
imho the point is not to reinvent the wheel.
what if i would need a widget such as a date picker or a rich data table, for example? should I write it myself? each home made solution may be worst than a proven well engineered one, and its charge for implementation and maintenance could be too much great.
if you need a car, you go to buy a modern one, I imagine. how many models of cars there have been? it's a natural evolution, or isn't it?
so, if you have to develop a new project, you take some modern tool (better if open source).
imho the only solution to the framework changing is to keep the design well separated from the coding, in order to easily reuse the former in the case the implementation would be rewritten to use a new fw.
My proposal is then: spend your time in developing something that may help you to generate the implementation from the design. too daring?
Exact same experience here. Tried porting a huge react code base (over 22kloc) to WC/litelement, and it wasn't easy finding a 1-1 replacement (even with libraries) for stuff like multi-layer conditional validation etc.
Will wait for part2 to see the solution because I do agree with some of this ranting. Hopefully this doesn't stop with part1.
I don't have this series planed out but I never wanted to say that they are an easy replacement.
What I wanted to say is that it would benefit the community because everybody would have on target and one common pattern on writing them.
Ditching frameworks for web components implies that frameworks only provide with a view layer, but is it true? If I had to build a scalable, big enterprise level application with web components alone, how am I to justify to the business the amount of time needed to go framework-less? By saying that FB will drop React at any time? In truth they're investing pretty heavily in it. And so is Google with Angular.
I totally appreciate the underlying meaning of the post, but looking at reality, and most importantly at real world business, I don't see completely ditching a framework, today, as a viable choice.
So how does reactjs help with big scalable apps?
You need a bunch of extra stuff starting from a router to some state management.
You can still use frameworks but they should be interchangeable. If you think about microservices then it would be the same issue if you would need to throw away the whole system just because you changed one microservice. This would be not a good pattern right?
FB will not drop ReactJS but google does throw away a lot of stuff if they think they don't need it.
With its ecosystem, tooling, 3rd parties, let alone how much people love using it. Do Web Components, today, offer the same? No. Will they? Who knows, maybe?
At AngularConnect 2019 it was said Google uses Angular internally for thousands of projects (source). I am not sure they'd be happy to replace them all over again any time soon :)
Google also invests a lot in polymer
Google was the main force behind web components
So why should they now ditch it?
Yeah, no such changes happen overnight but at some point, we have to start. At some point reactjs was only used by facebook now it is everywhere ;)
I think angular has an option to use web components for a lot of its functionality. I would guess google will push more towards using that in the future.
Yes, they will!
They started that web component thing in the first place with version v0.
The React core team has literally no plan if Facebook stops that investment or moves on to something else. And, unlike some other open source projects, React's staff and destiny are entirely employed and controlled by Facebook.
Web components can be used in another way: as a standardized glue between different frameworks developed as microservices.
hackernoon.com/front-end-microserv...
I developed in the 3 big frameworks (Angular, Vue, React) and the best thing is they promote best practices: component-based architecture, one-way binding, handling application state separately. Yes they change, but I think in a good direction. Just look at AngularJS -> Angular...they introduced one-way binding. They might be not the best possible, but are aiming in a good direction...and it involves change. Change can be good ;)
I hear you, that web components can be a glue between the big 3, Angular, Vue and React. But truthfully, when you see the power, simplicity and flexibility within the "standards-body way" of doing things, you'll realize you are just gluing heavy ass bricks together with elmer, it's just baggage and lots of it.
I love this meme, it brings it into focus:
thepracticaldev.s3.amazonaws.com/i...
There's no simplicity in a production implementation of native web components at scale. It's very complex and inefficient
That's what you think. What do you mean?
managing renders, lifecycles, attributes/data-props, data and event binding, and usage of node_modules -all becomes a bit of a nightmare when you do everything manual in a web component.
Going vanilla -you won't have builds and bundling.
If you don't want to use libraries you'll just end up writing your own and basically implementing your own framework by the time you're done, and it will take a long time and you'll be debugging forever.
If you use libraries you will make some of these pain points easier, but you won't have proper bundling or node_module handling unless you do a webpack-type config yourself. If you use libraries for rendering, data-binding, routing, etc -then you're practically using a small "framework" like React/preact.
Don't get me wrong, I'm all about progress for the bare-metal specs. I even wrote a web-components boilerplate that solved a lot of my problems and am still working on a native SPA router. However, I found that as I kept working on a long term plan -I found myself just re-implementing SencilJS, so now I just use that.
Hmm, where have you been? I'll contact you from your resume site.
Actually this is ironic, i worked at the same place as you and got fired for using a native Web Component-style implementation because the lead was confused, made a fit about it, we had meetings to discuss the repercussions, risks to the team, and why it looked so different compared to his million jquery scripts vs my single-class files. I was told that i was high risk to the team and immediately fired, no pay.
Besides folks there are completely closed minded f*cks. Peace bro.
Feel free to reach out. You sad we worked together, where was that? Feel free to DM
Where was this?
Implementing the same functionality with libraries using webcomponents will also result in big node_modules. Luckily not everything is included in the bundled application thanks to intelligent bundlers.
Been programming for 20+ years, I've seen frameworks just die and you're left with a pile of out dated and poorly supported code.
1 thing has not vanished, and it is w3c/web standards.In just a few more years react and angular will be bad legacy ideas
@Joey D. - Not a good example, but i think i see your point, you can say that http header spec went through some kind of change, but that change is still confined to a "path" in a well-defined and stable HTTP Architecture. An Open-Closed design allowed the evolution of http headers without breaking the overall architecture.
What we have today in UI are companies partitioning the once simple idea of making a page into proprietary ways to make a webpage, ignoring the spec body and producing their own, which is not all necessary (VDOM) and is actually quite profitable for companies like [name here and here] to increase revenue along just another venue by way of "talks" and shows, and events, video, training and popularity.
Hey, you have all the right to innovate.
Exactly!
And if we build frameworks let build them so that they are built around w3c standards!
StencilJS
Yeah and there are more frameworks :)
You couldn't be further from the truth my friend
Sorry, who?
and what truth?
Plenty of web standards are abandoned and lost to time. Just look at the history of http headers.
Yes and sadly so many god ones :(
Reasons to use Angular:
All of the above makes it easy to work on legacy code or to collaborate with colleagues.
Its not the components that make me want to use it.
I never understand the comparison between the two. React feels like a toy to me when compared to AngularJs or Angular.
Everyone is talking about components like it's a new thing. Web Forms had this idea 15 years? ago. Actually I liked Angular because it reminds me a lot of Web Forms and I could use the same flow. Razor pages? Can't see how it's not Web Forms in a disguise
AngularJs and Angular are not so far apart like everyone likes to say. Actually I converted a big application and it was mainly syntax rewrite.
I'm dying to get rid of javascript :) It's amazing that we are still required to bundle files in 2019 instead of having an engine that can run anything inside the browser...
There is an actual engine inside de browser parsing and compiling code! Its called V8, SpiderMonkey and many others. The thing here is about your personal preferences; looks like you don't like JavaScript very much when it is the only programming language the browser directly understands.
I said that I don't like Javascript :) It's outrageous that we have to settle for it even with TypeScript which improved the situation drastically. It's still an inferior language (and this is not a personal preference). Anyway, I complained about bundling. It may look natural that you have to do it, but this is merely a compromise. There should have been a better more elegant solution by now, And I work very hard every time to hide this burden from my developers, bundling is not something I want them to waist their time on.
Maybe they are we will see :)
I'm not disputing that at all.
But we as a community of web developers are working on frameworks/libs that have been already solved several times.
My point was maybe we should rethink that and try to come to a common design pattern for components?
In the end what I have seen that Standards will survive libs/frameworks will not.
separation of concerns - wrong. HTML and JS/TS are not your concerns. Your app features are.
built in directives and template syntax - oh you mean the ones that don't really work well with typescript?
forms, router - nope, forms are hard everywhere. at least with react libs like Formik makes at somewhat bearable
standard code and design patterns - oh you mean those patterns that make the code look like a bad corporate JAVA where you need write 10 keywords, 5 decorators just to define a property? No thanks.
testable code - who are you kidding? angular can't even render a component into a string. Do you expect me to only test in full DOM? Shame on you.
typescript - how dare you attribute this as to angular. You can use typescript with any other framework.
its an actual framework - bad framework. For example they recommend rxjs for state handling which is total overkill for 99 percent of web apps
continuously maintained - with already 7 breaking versions? Where they often change arbitrary syntax for little benefit? No thanks. I'd rather react
"All of the above makes it easy to work on legacy code or to collaborate with colleagues."- lol I just finished on a corporate contract where we used angular 6 and 7 and it was a total shit show. Total opposite of what you paint here.
There are many types of concerns. The separation of concerns along which HTML, CSS, and JS were designed are real. They reflect the persistent concerns of user interfaces across most projects: what is this information, how should it look, and how should it behave? And they served those concerns well when we were making simpler content oriented documents that weren't bursting at the seams with a single scope. What the platform has failed to give us is a way to separate by project specific concerns, business-centered concerns, suitable for increasingly complex applications. Frameworks concentrate on the latter and very few, perhaps none, have reached the same bar as the web platform for meeting the needs of diverse devices and empowering copywriters and designers to contribute. Web component features like Shadow DOM are critical in enabling business concern separation while also maintaining the web's unique value propositions for audiences wider than engineers.
Your ultimate argument is you hating the framework. You also might be confusing Angular with AngularJS as well. You got the right to your own opinion though. Cheers.
Web Components actually work well to compliment frameworks. They aren't mutually exclusive technologies.
I use frameworks to manage the state of a view or an application. Web Components allows me to re-use elements across multiple frameworks, or none if the site or app is basic enough.
Good luck trying to use webcomponents with react.
Done it. It works. With TypeScript, no less.
Maybe I'll put together an article to show how it's done. 🤔
Was it easy?
Yep.
I would love to see that blog post :)
Look into direflow.io. They make it super easy to bundle a React component as a native custom tag Web Component.
I know what you're getting at, it would be very nice to have a standardised way of doing something, and only ever use that one way.
However, I whole heartedly disagree.
My first point on why I disagree: if we all work inside the box, where's the space to innovate and create something better?
Next up. Your attack on frameworks and libraries and how overchoice leaves you paralysed.
Firstly, frameworks and libraries are different. Frameworks are an out-of-the-box solution for most of the problems that a developer will run into when developing their app. Routing, forms (to give your examples), state management, XHR, debugging, testing, performance optimizations etc. The framework will also usually come with a set of best practices, and guard rails to ensure you are working within a set of constraints that will empower your and your colleagues and allow for more maintainable codebases.
Libraries on the other hand are generally focused on solving one problem and solving it well.
React can be composed with many different libraries and solutions meaning every react project could have a different architecture, but one that could fit the business problem more efficiently than a set in stone standard provided by a framework.
By having different options out there, it gives every frontend architect the chance to look at each option and analyse which option will suit their team better, and will solve the problem that they are trying to solve best.
Who is to say by choosing one you can't use any of the others? With tools such as Nrwl's Nx Workspaces you can have React, Vue and Angular projects live side by side and share code between each other.
Next up, web components. Amazing, truly standardised way of creating reusable pieces of code that can be shared across projects and dropped in. But does it out of the box solve your state management issues? Provide a maintainable approach to structuring your app? To guide developers on how they should be internationalising their small reusable component?
Frameworks and libraries aid development as they provide a starting point and guide on how to wire together all the components that make up the full application.
Out of the box, web components, and correct me if I am wrong, do not support server-side rendering which could lead to performance and potentially SEO issues for customers down the line right?
There can never be a one size fits all in software development, otherwise we would all only be writing in one language, Assembly, and we wouldn't have libraries and frameworks, and we would absolutely hate being a programmer and we would never be able to innovate or prototype or scale out applications to the global scale we can now.
Web component do support SSR. You just need to extend existing html components instead of just creating new ones. Some libraries facilitate this. Take a look at heresy and heresy-ssr (there are other).
If you are unsure where to start with Web Components, this is probably the best resource I have been able to find, that is friendly enough for anyone to understand. If you are a React Developer, this new technology will be a breeze.\
dev.to/thepassle/web-components-fr...
Thanks, I will have a look at it
So framework X comes along. Devs try it and rave about it. More devs sign on and soon there's large wave of devotees. Lots of software gets written. Business rules get encoded. Bottom lines begin to depend on the framework.
And then another wave comes through. Its actually not that easy to rewrite everything. Nor is it financially viable. What do you live on while everyone scrambles to re-tool and re-write? And since when has a rewrite not injected idiosyncratic language- or framework-specific bugs into a previously stable, mostly-debugged system?
This is why there are still multiple millions of lines of COBOL out there running on mainframes -- the cost of change becomes prohibitive. And what do you run while you wait for the new stuff to arrive? And why bother waiting for new stuff to arrive if the old stuff works? And what do you rewrite it in if the sea keeps changing? There was a while there when folk actually talked of replacing Fortran with Forth and COBOL with Java.
What's missing from the meme at the top of this article is the sprightly octogenerian grandmother (labelled COBOL) who rolls her eyes at the immaturity of the young man's wandering gaze. She still riding her wave.
The problem is that banks for example now how problems of finding these grandmother's 😄
Yes. Which is why I was on comp.lang.cobol recently trying to convince folk to get a COBOL course running on exercism.io. They didn't exactly jump with excitement over the idea. Yeah, setting up a course isn't a simple process but even so there's money to be made knowing COBOL.
That's true!
If you know COBOL you can make a lot of money!
Because banks, for example, want to solve everything with money ;)
I'm looking forward to your next post on this topic. It's interesting but I'm not sure I fully share your view. But I'm not going to comment on the technical parts of the whole Web Components VS Framework debate as I believe others have done it better (Rich Harris for example, in dev.to/richharris/why-i-don-t-use-... and in the surrounding discussions on Twitter).
Though I believe that some parts of your reasoning feels a bit fragile. Like "[...] if you are really honest to yourself, then you would probably still be happy with class-based components". I think this is a naive and potentially hurtful way of reasoning that limits progress and technological advancement. Imagine someone saying "if we didn't invent the wheel we'd still probably be happy to carry all the stuff around on our own". Yes, if we are not aware of, or chose to ignore, alternative ways then sure, we'll be happy with what we currently have. Because we don't know of any other alternatives and we don't aim to improve the current process. I don't see how this argument adds any value to the debate.
Concerning hooks specifically, the marketing (from actual React maintainers) has never been "Hooks are extremely superior, you should rewrite all your class components NOW". Some members of the community have maybe tried to convey that message, but I really don't think that "we have been tricked by marketing". Can you point me toward some of the marketing you're thinking if? If it's mainly community created posts and opinions I instead wonder how you classify marketing in this case? Reading the official adoptation strategy FAQ (reactjs.org/docs/hooks-faq.html#ad...) I think it makes it pretty clear that they don't expect anyone to rewrite or scrap all their old class based components. Sure, they encourage us to try the hooks API, but I don't consider the marketing very problematic, authoritative or controlling. I think the difference between official marketing and community opinions from individual users should be made clear.
You're also discussing the risk of having too many front end frameworks to choose between and how it paralyzes people. Is that really the case when it comes to general UI frameworks though? React has been around for 6 years with very few breaking changes. Vue.js has been around for 5 years with very few breaking changes. Angular has been around for a very long time, unfortunately can't say the same about few breaking changes here though.. :P
Do you find this enough to impose "overchoice" and paralysis? I don't personally think so. Sure, there are lots of other frameworks and libraries in the JS ecosystem, but you seem to be mainly talking about more general UI frameworks here. If we're talking about JS libs in general the reasoning also applies to a development process focusing on Web Components. And if you think we need to consider all smaller frameworks as well, than I'd say that the situation in the JS ecosystem isn't very different from other languages. If wide adoptation is of no importance then you'll be able to find quite many obscure little libraries and frameworks in the .NET or Java landscape as well. That could impose paralysis if you choose to not only consider the main, widely adopted, alternatives.
UPDATE: I see you've clarified that you're "not against frameworks! I'm against everybody doing its own thing!". I partially agree with you about that, but with some of the thecnical inconveniences of Web Components I'm not sure I believe it's the best option. And if you're fine with using a Framework on top of WCs, than I believe everybody will still be able to "do their own things"? :)
I don't have anything against frameworks.
What I want from these frameworks is to target web components.
Everybody is still free to do what they want!
Ah okay, I think I got a little misguided by the post's title them. So you're meaning kind of like Svelte 3 is already doing? (although with an optional compiler flag) My understanding is that the current WC spec is challenging to work with to achieve some patterns and features that are considered needed or very useful in frameworks. Which is why it might make more sense from a framework perspective to only optionally target WCs in order to fully support some features without a lot of extra hassle and workarounds.
One problem area that comes to my mind is the Web Components total inability to handle SVG content conveniently due to elements needing to exist in the html namespace
The moment I can turn my reactjs component into a web component I would be happy!
SVG in general are kind of challenging but that's IT in general
Check out direflow.io/. It packages a React component in a Web Component 📦 and it provides the glue between attributes and props.
So, while I look forward to your next installment where you will hopefully prove me wrong, I disagree with your premise. I've worked with web components, react, angular, and Vue. Based on this experience, I would never willingly choose to build an app purely with web components. The spec is still immature, the code required is extremely verbose, the style of writing is imperative and reminiscent of the old jQuery days of manually constructing HTML with JS... I could go on, but that's my opinion. It would be great if we had a native solution that didn't require the frameworks, but that is not reality yet.
Exactly not yet!
So we have to work to get there and it would be nice if more people could work together to get there right?
I don't think web components will ever be more than a fruitless idea. What did they think would happen, they created an imperative, dom-bound, vendor-controlled view layer that yields a naked dom node. And it shows, usage stats are in steady decline.
React, at least in numbers, has won. And it hasn't just won the web. It is surely better than embedded browsers, waiting out vendor in-fights and shady policies for features, or getting served questionable features without merit. This is what the web was always about, things develop and progress when they're actually good. Technologies aren't served, they evolve in accordance with how the community responds to them.
Btw, you keep mentioning Polymer. They have broken every promise they ever made. They had more hard reboots than any other framework including Angular, forcing people to rewrite their code from scratch. They had absolutely no vision other than "standards", which curiously were ever changing and still can't answer for a fraction of what frameworks solve today. It was clueless as to what people actually need, they thought npm as a fad basing on ... bower, they actually believed people wanted to import html's. And like always, the people that are going on about "framework fatigue" are the ones that are actually experiencing fatigue - through so called standards - but no one else seems to have these problems.
Right now reactjs is maybe in the top but like every framework in the history of programming will go down but we will still have standards. Yes, these standards will evolve and that's a good thing.
I would rather contribute to a standard then a framework that will be gone in 3 4 years the standard will still be there.
Maybe not in version 1 but 2 or 3.
view=function(state) is a paradigm, which is what matters. Paradigms don't change often, controller based mvc just had a decade.
Standards don't fall out of the blue sky. React was initially a great idea that has practically brought about a paradigm shift. It has been influenced by millions of developers world wide putting it to use. And it has proven to be flexible enough to adapt and renew itself, which is the hardest feat.
Since browser vendors are implementing these specs and you don't longer trust these standards.
The only conclusion I see right now and please correct me if I'm wrong. You will work against these standards? Or what is the conclusion here?
Or should we fragment more and we will be the next "year of the Linux desktop"?
Browser vendors have implemented scores of useless features that were later abandoned (object observe, etc). That is why they have made the extensible web manifesto, which was supposed to prevent this from happening by explicitly focussing on the low level. WC, once again, break that ideal. It isn't about trust, it is about merit, no one is foolish enough any longer to just blindly go along with features that have no merit. The web is mature enough to let certain things develop outside of the spec body's grasp - the high level, component abstracts etc is something that should never be set in stone as it needs to adapt to the ever increasing requirements. If web components can't even fulfil requirements we had 10 years ago, not to mention todays, how are they going to adapt to the future?
Do you realize that you are talking about web components? I've seen such articles for 10 years now with nothing to show for. Yet all the spec would cause, if it were adopted, is fragmentation since it relies on frameworks to drive the exposed root node. But since the proposed component definition is inherently flawed (imperative, mvc controlled, templates, embedded browsers on mobile and iot, all the things that we have finally put to rest), the fragmentation would be devastating. The spec simply does not solve our problems, and that's the reason it is withering away.
V=F(S) is a single, cross platform standard that actually works and has been accepted by the community at large. It is the first time that we can serve multiple platforms with the same components. It is also the first time that platform differences flatten out, web, mobile, native, ar, vr, everything can be targeted. It has done in a couple of years what the web couldn't do in 20. Yes, React, or rather the paradigm it has created, is more of a standard than the specs body could ever dream of, so what are we complaining about?
Except Web Components are paving the cowpaths in a way a lot of abandoned standards don't. They also have a viable opportunities for allowing script-free extension of HTML. Since JavaScript is fragile and expensive, this is pretty critical. You'll notice that the standards the React team is collaborating on don't feature this paradigm. There's a reason for that.
Check again web components specification and all the resources around the web from google, stencil, and open web components. React and web components can't be swapped because they do a different thing. Web components are made to extend HTML and to make new leaf elements, not applications or big components. They should be simple, add functionalities to HTML elements and use composition (one of the core concept of HTML).
Sounds to me like what reactjs wanted to be an ui framework to for creating components.
ReactJS has no data layer that's why we need things like Redux etc.
Maybe it now has something with hooks but I think it is still to early to say.
React can't create custom elements or extend the built in ones. React, as an abstraction layer can of course handle their components, but they're just logical containers that render html elements. Web components are THE html elements you should render inside react, as for the built in ones.
So I could argue both ways.
Why then not use react fully? Or why not use web components fully?
You can use react fully, but you will have the react dependency. Wc are framework agnostic with no dependencies if you use vanilla js. With react you can't create or extend native html elements, (this is the point of web components) you can just use then the html elements you have and combine them to build a new widget. While with web components you can't build apps or complex things because you work directly with the platform api. They are on a different abstraction layer, as I said here:
css-tricks.com/making-web-componen...
Okay, thanks for the link!
I will read it!
I think that's a very good point; the abstraction layer. The link above puts it well:
Web Components seem to be at the leaf level of HTML documents. I don't feel comfortable when folks say that an entire SPA should be enclosed in a single Web Component.
Couldn't agree more with the fact that the Web Development environment is convoluted and that we are just reinventing the wheel, in cooler ways, to do the same thing, and not getting anywhere. Web Components are a low level api and not for direct use, both a good and a bad thing. LitHTML and LitElement are probably the most commonly used tools for Web Components right now, but these are obviously in their young stages (Lit HTML is backed by google and we all know the fate of most google projects).
This is one of those points where Web Development takes a turn, one bubble pops and we focus our energies onto another, more promising one. One thing however is for sure that the Web Components API is here to stay, and to replace the Framework mess, whether everyone wishes to accept this or not.
Yes! and Yes! 🤣👍
Web Components are kind of low level but I don't think that this is a bad thing.
Right now we producing web developers that don't even know basic HTML or the don't know the difference between git and GitHub.
So some kind of understanding the low level would be a good thing at least in my opinion.
I don't think it's fair to say that frameworks are producing web devs that don't know basic HTML, most of the UI libraries and Frameworks still involve the dev writing some form of templating code.
NativeScript with Angular is the one that pops to my mind that doesn't use HTML itself.
Also, with the development of web components comes the introduction of more libraries, frameworks and tools to create them.
StencilJS, Angular Elements, Polymer etc.
Will the market be flooded with too many libraries and frameworks to develop web components 2-4 years down the line?
I work/teach juniors.
Some of them can't write a static website without reactjs or some other framework.
I think this is a problem because they don't understand the basics.
The thing with having stencil or polymer as that I don't care if they are written in whatever framework I just import the web component. This should be the goal.
Of course, all of this has its own challenges
I go to school with many of the same kids. I think the problem with young devs not knowing how to write basic static sites is due to the lack of structured courses in higher education around web development. Young devs usually like to go for whatever's new and flashy because that's where the jobs are (or so we're told). Few people understand that the fundamentals are more practical to learn in the long run.
The fundamentals are of extreme importance. Sir James Galway, the world famous flautist, said as much in this posting regarding the value of learning scales.
Long story short: use the framework that works for you. Even if it's polymer, say on a small project, though I advise, from experience, to steer clear of polymer for larger projects - it gets frustratingly slow frustratingly quickly.
@Davyd, did you try the latest Polymer releases (LitElement, Lit-html...) is it the same as Polymer? I wanted to try them.
I haven't. Give them a go if you have the time and let us know.
It's been about 1.5 years since I used polymer, and I haven't missed it one bit. But there's always room for an improvement 🙂
I still need to learn some stuff before doing that. I'm trying to check by myself if I can get rid of frameworks and use only html CSS JS for my little personal projects. I still need to know how to make a router and spa without framework, how is it to do a loop like ng-for/v-for in pure JS and if it's worth it, and check the compilation with npm babel etc without the great vue cli 3.
PS: I'm a UI developer, not that much of a front end engineer
I've heard some really good things about svelte too, and it might be easier to get into, considering that, like vue, you can integrate it piecemeal with your existing html. It's definitely something to keep on the radar.
Isn't it another framework or library we could avoid?
my opinion is that we shouldn't be simply looking to avoid frameworks (:
if you just need the smallest amount of logic (or none at all) in your web page, then sure, vanilla js, or nothing, is good.
but if you're looking for some kind of updating component which does stuff, I don't want to (personally) do the heavy-lifting that a lot of other talented people have done before me -- in this case, I want to use a framework so that I can concentrate on my application logic, not re-inventing the wheel (and dealing with cross-browser issues)
I'm advocating that people use the tooling which works for them -- don't use a framework just because it's "cool" or someone said you should. Don't ditch your framework because someone else said theirs is better, unless theirs actually does work better for you. Best of all (coming back to the OP), don't propagate the FUD that web components are a "standard", when they are just another framework, unratified by the W3C, pushed by Google. Do you remember the debacle last year when Mozilla complained about anti-competitive behavior where YouTube was signifigcantly slower in Firefox? That wasn't Google outright throttling YouTube for Firefox users -- that was Google assuming that they're too big to fail, baking their framework into Chrome and releasing a new YouTube using their framework, probably hoping that it would drive up the desire to make web components a standard.
Anyways, like I say, I don't have appreciable react experience, but if you're getting stuff done with AngularJS/Angular, Vue, Polymer, Svelte, whatever (I've also used a couple others, including CanJS for a prod site and a few others I've dabbled in, including Knockout and Ember), then carry on getting stuff done. If your framework is working for you -- use it (:
My suggestions are based on my experience:
/2c (:
Thanks for your answer.
OK so I'm going to check out the web components world and see if I can switch to something different or continue with Vue (I love Vue, it reminds me of the JQuery days, lots of freedom)
Good idea -- that's the only way to form solid, useful opinions about frameworks: build with them, see what works and what doesn't, what's easy and what's hard, what's a pleasure and what's a real pain.
Personally, if I were about to build something new, I'd pick Vue if the project Really Mattered or if I didn't have time to experiment, otherwise I'd like to give svelte a crack (:
Some comments may only be visible to logged-in visitors. Sign in to view all comments.