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.
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
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.
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
Comment marked as low quality/non-constructive by the community. View Code of Conduct
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?
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.
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.
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.
Writing about my experiences as a Bar Raiser at Amazon. All opinions, alphabets, punctuation; and grammar here are my own and do not represent my employer.
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'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.
You mean to say only using standard HTML markup and OOJs
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!
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?
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.
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.