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
Oldest comments (248)
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.
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
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.
Bold
I don't really know what to do with that comment 🤣😅
I wrote a reply . . . then
mistakenly erased it🙄Bold because the evergrowing garden of coding bootcamps and fast-paced web-dev schools (my dear Lambda School included) spends an inordinate amount of time creating projects and tutorials to master the hottest & latest JS frameworks with a half-life shorter than Francium. I agree completely, and it feels like we're all going our own paths with web technologies which may let beginners explore COUGH|
anDjOiNtHeCLOjUREdaRKSiDE|COUGH languages and paradigms more creatively.¯\_(ツ)_/¯Italics
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.
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.
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!
You mean to say only using standard HTML markup and OOJs
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
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.
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
Exactly!
And if we build frameworks let build them so that they are built around w3c standards!
StencilJS
Yeah and there are more frameworks :)
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 :(
@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.
You couldn't be further from the truth my friend
Sorry, who?
and what truth?
What's so hard about routing with
react-router-dom? It only takes an import, and one line per route.oh, react-router...
Updating the codebase from v1 to v2 to v3 to v4... no, thank you!
I'm a burned child here
You should take a look at what the Angular Team are doing with their CLI tool and how they're writing migrations to automatically fix any breaking changes within your codebase as they progress from version to version by simply running
ng update.And they do it using an AST rather than a RegEx to maintain the correctness of your program.
Yeah they maybe do it now
and these code mods have their limitations.
the react team has them too.
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...
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.
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?
I Like the way you talked about components should support any framework, even I'm trying similar approach from past 2 monts. Eagerly waiting for the next post 👍
Can you share a little bit about what you have tried?
I would be interested in!
Centralising of all components in a structure way n moved most of the code to helper files, so that I can plug n play my component in any framework.
This is how it was promoted by some other frameworks. Having business logic not in the view logic 😄🙌
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 agree that standards are important and should be developed for the web. I also think that libraries and frameworks like React and Angular were developed to solve the problem caused by lack of standards, but also because to generally took too long to do a few basic tasks.
The differences in how we approach solving problems represents our unique ways of thinking about them, so there was definitely going to be variations as seen by the existing libraries/frameworks. I also think that some people (probably like me) didnt really get into the band wagon because one library was backed by one "big company" but because it offered a way to solve a problem and I could either go with it or not. This kind of diversity is what I find liberating for me. (I might be alone on this). So standards are great, are welcome but should solve the problems without taking away the ability for people to express themselves, afterall that could be why some of us started coding.
I see it a little bit different
With web components I can express myself not only to the reactjs community but to the whole web community so I have a bigger audience
I agree with the sentiment, but it's less practical than React, etc.
Some problems with vanilla custom elements: You can't pass around objects, you have to handle DOM updates manually and elements must be uniquely named.
Of course you can pass around objects. It's plain JavaScript. You can write modules using design patterns that allow you to do this. DOM updates, don't have to be manual. See Observer Pattern.
You've started an interesting article. I look forward to the next one.
I get your point about the standards being a better way to develop for the web.
When I first started learning react, I got this feeling of absurdity.
I started with html in '99.
It was like most of this is meaningless after you build the project!
It compiled into minified code completely unreadable.
I also got concerned with the future of these frameworks and quit learning react. I chose Vue instead. Mostly because I don't trust fb and Angular showed me what any of these frameworks could become.
I'm not completely convinced of Vue either, I like how it's not owned by one of the big three. These frameworks essentially do the same thing, just slightly differently.
I don't know where I go with this series
I did not think that it will get this much attention.
I'm now developing web things since 2006 and I have seen this cycle several times now.
But in the end, what has been always there were the standards.
Even if Javascript now is not what it was 10 years ago it is still mostly the same just with more features.
Really really hoping part 2 is where you explain how much farther along and well defined the web components standards and cross-browser adoption in the past year or so is now surprisingly mature. Otherwise I would say your arguments are invalid sir
If we leave out the web components part and just look at the first part what would you think about this blog post?
Then it would be a mixed bag for me: while you're showing the kind of genuine dedication to finding the simplest and most elegant ways to build UIs, it also contains the kind of minor/medium flaws that come along with idealism. There are genuine obstacles in the way of reaching the most elegant and ideal ways of building the kind of front end applications we'd like to build.
For me, working on large JavaScript applications prior to jQuery, Bootstrap, and Angular 1.0 gives me an appreciation for the improvements those frameworks brought to help me get my work done. The sunsetting of those frameworks and making way for ones that offer more simplification and improvements to new problems (or ones the older frameworks couldn't solve very well) are worth celebrating. Throughout the article here I ran across sections that hint that you might not have as much of that history under your belt to notice ways you've come full circle or are suggesting solutions that re-introduce old problems.
So far Polymer seems to be one of the better ways to work with web components in a scalable way, but it has limits and (hopefully you'll shed some light on this in part 2) I'm curious if browser support is far enough along to base a front end architecture on it that can scale to large teams for companies with heavy public facing traffic.
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'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.
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...
Maybe they are we will see :)
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.
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.
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.
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.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.