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, A...
For further actions, you may consider blocking this person and/or reporting abuse
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 :)
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 :(
You couldn't be further from the truth my friend
Sorry, who?
and what truth?
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
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.
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?
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 ;)
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 (:
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
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.
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.
Thank you for writing this and reminding me that being a good developer means using technology where it adds value. I realize that I let myself get caught up in the hype of these frameworks that are really providing my project with no value beyond "bragging rights" that our app is using React. The fragmentation and interdependence of these new frameworks bring to mind the old DLL hell of the fat client.
I don't like that the community is running around like sheep.
This week this framework next week that framework but they solve the same problem just in a different way without adding value to the product.
I have seen teams that did a rewrite in reactjs/angularjs/vuejs and the user experience was worse than before.
I'm not sure why this argument about frameworks sucking continues all over blogs and YouTube. I mean c'mon guys, as developers we have to stop resisting change. Every industry continues to grow no matter what industry you are a part of. If this logic was correct we'd all still be coding in Pascal. We have to deal with it. Nothing lasts forever. And we have to continue upping our skills. This would be the same in the education field, marketing, accounting, etc. There will always be new research, and new ways to do things. And when you continue learning it's called professional development. I'm sorry that the web is not some static unchanging thing, but it is and technology continues to evolve. And with evolving technology comes new tools and evolving tools at the least. I mean if anyone wants to write your app in vanilla JavaScript everyone is completely welcome to and skip a framework. But frameworks will continue to grow and evolve. I think part of the problem is perhaps people not picking. Just choose one and continue to follow it on its path. If you're angular be angular and follow the community. If you're react be react and just follow it. So then you're not as shocked when changes and upgrades happen. But we cannot continue this argument that code should never evolve and continue complaining about frameworks evolving.
Mhh I don't fully understand how you came to the conclusion that code should never change?
I was saying that we should now jump to the new thing: Web Components v1.
They were released way way after react,vue or angular.
Maybe this was my fault but I'm not against frameworks I'm just against splitting up a small community of developers who actually contribute to these frameworks and then make them even smaller.
One of these days I'll have the guts to explain why I don't use any frameworks, but do use consistent coding patterns that sometimes look framework-y.
Might partly be because I tire of the constant debates over frameworks instead of getting work done.
I'd also be interested in a post on this! We recently started using VueJS, but now SvelteJS is also starting to look very appetizing, and I'm sure in a few months there's another way building web apps and that will start to look really nice. I find it hard to make a choice and stick to it when it all moves so fast.
Looking forward to that! Please post this online!
Not meant to be offensive
What is this some kind of web development socialism? The reason frameworks exist because they serve a purpose and they are good at solving certain kinds of problems.
How can you tell that some way of doing things is better than other, before applying that abstract idea to real world problems. Think of frameworks are kind of lab rats to test ideas. why are you so hung upon them after all they are based same old ideas and new shiny syntax. There is no holy grail, one size fits all programming language/paradigm/framework.
coming to linux example, i use i3wm, and it solves my workflow problems very well. Does that mean everybody has to use it? or somebody using xfce/gnome/kde is wasting their time?
Let us see, when web components become popular, we will then have people talking about why they are a poor way of solving problems just like they are complaining about jquery (it was awesome when it was released).
If everybody works according to your or my wishes, then our ideas are absolutely correct. If we are absolutely correct, that mean we know everything and can predict everything which will never happen. so everybody will work according their own wishes and will produce a new framework(next update react anchors!! to be released on fall of 2020!)
I'm not against frameworks.
We are already building for one target it is called web. The web does support only html css and js.
Posts like this tend to promote an unrealistic view of Web Components. Or atleast Web Components in the current state. As I'm sure re-iterated many times in the comments a Framework replacement they are not. I've been using them in production (polyfilled to be sure) since 2014 and I think generally the wrong comparison is being made. People still generally need tools to make working with them easier a library/framework of sorts. In fact, I would say Web Components are some of the biggest culprits of Library fracturing. They provide just enough that every would-be library author now has a framework. I can't help but feel it starts from the sentiment presented in this article.
Admittedly I'm guilty as charged of being one of those. But I think it's more interesting where popular libraries have tried to align with Web Components (I'm looking at Vue, Svelte) and now have diverged or would not recommend using them.The reason is simple. Beyond not being wholely up to the task they are primarily DOM oriented. It makes sense but it means silly small things like eager versus lazy evaluation of slots, or lack of declarative Shadow Root, or event retargetting interfering with event delegation gets in the way just enough. I mean libraries have been developing techniques to better interact with the DOM that aren't quite compatible with Web Components. Now obviously we can say "React your synthetic event system should no longer be necessary so get rid of implicit event delegation to be compatible." Or maybe we shouldn't. There are solutions to resolving composed paths for that specific example. And there are lots of different ways to solve similar problems. But it is still something.
I think another thing we don't talk about is their natural overhead. There is a difference between components and Components(TM). What I mean is that components as containers Web Components are adequate. Defined contract of API, encapsulation, modularity. However in a library like React that isn't how or why you use Components. The patterns being used by libraries have just as much to do with performance or mechanical reasons as they do for containerization. Web Components are a much heavier construct than those. Thinking you can use them interchangeably is a big mistake on scaling performance.
All that being said I think Web Components are important and have the potential for a lot of great things. I just think that this sort of argument is so easy to poke holes in that it will never get consensus. Web Components are not the same as those libraries. They can cause just as much fracturing of solutions. And they come with just as many specific tradeoffs. Accepting that is where the real conversation starts.
To say it in a shorter way:
"IT is hard" and yes it is!
But I rather work together with the people on one goal then everybody supporting just there team.
But that's just my opinion :)
I'm doing routing and form validation using Angular and I have absolutely no problems in doing that. Very satisfied with Angular, as well as it "small splitted community" and I like the way it is. Easy also to find developers who knows a common framework, so it does the work perfectly. I am for "Standards", but I disagree with most of the things you've said here.
You can disagree that's totally okay!
Just please don't bet on one framework. In my region (Europe) when looking at job postings angular is going down and more vuejs is asked.
Every framework/lib has its time and in the end will die.
What you're suggesting is basically a monopoly. Monopolies are bad for innovation. If we all use one thing then progress will be very slow and evolutionary as opposed to revolutionary
Mhhh calling a standard a monopoly hmm
I think we have two different understandings of the word monopoly.
Where is the company here? 🤔
Monopoly doesn't describe a company - it describes exclusive control of a supply. If everyone is using a single standard and nothing else then the standards committee are those that have control and use it. In this case the supply is actually options/ideas/ways of solving a problem.
Let's not forget that most things that go in to a standard were being used before they became a standard and they became a standard because they were popular. Using things like React/Angular don't always a standard they extend what people do beyond it - but even if they do - then they do so bringing new ideas that may themselves become a standard. There is a reason why they're popular.
So HTML, CSS, and Javascript are also Monopolies?
I'm pretty sure we have pre-processors that allow other languages. So if we take it to that level what you're saying is everyone should use JS and not use any other language such as Typescript. What I'm saying is that even Coffeescript had good ideas that have now been taken in to JavaScript making everything better. Web Components are basically a library built on HTML, so if we go back we could say "Time to ditch web components and use better standards such as HTML!". Remember - web components came from the Polymer project.
I'm all for usunig and learning html before usunig reactjs or Angular!
Sorry if this response is all over the place, it kind of got ahead of me and I was trying to bang out at least a somewhat thoughtful response before I had to go to work.
As a million people in this thread have already said, I feel like web components and frameworks solve different problems. I do think frameworks should work to target WCs where it makes sense (isn't Vue working towards this?). Extending built-in HTML elements is very cool and currently underappreciated, but to me it seems hard to justify building an entire application around it, in the same way the argument a few years ago could have been "yeah we could use frameworks, but we could just as easily write
document.createElement('div'); ...ourselves!There's been a lot of talk about "frameworkless JavaScript" but to me it misses a couple of points.
(there's probably other things but these come to mind)
I don't entirely disagree with you but I'm certainly reluctant to buy into any "one size fits all" kind of solution.
Dude, framework aren't only about writing components, like let's say react, having declarative helps so much, how about states and redux, you just update your state and everything else takes care of itself.
You can't seriously think non-declarative is better do you?
There's also routing, doing stuff in client side to reduce load on server, etc,
Have you tried sveltejs?
I think you will like it :)
For me, it is better react :)
Build-in router and state management and no need for things like react-router or redux!
Your title suggests to ditch framework and go with web components, I doubt sveltejs is a webstandard and not a framework.
I'm not saying to ditch frameworks. Just that the once we have should target web components instead of making up there open things 😊
I've to say, I don't appreciate these clickbaity titles...
What would have been a none clickbaity title for you for this blog post?
If it would have to be catchy and just a little bit misleading you could have used "You might not need Angular/React, WebComponents FTW!" or something like that. But the part about ditching angular and react is just plain stupid, as you kind of admit yourself in another comment here. They are tools for a very different kind of task. You would not build a complex app with just web components (you will at least need some other layer for all the business logic) while they are probably the best choice for the job if you want to build a UI library of some sort.
I don't know why it is miss leading or why I'm stupid but okay.
Your opinion and I respect that!
I chose the title because I felt it was the right one.
If you just want to build any UI to get the job done probably jquery is good enough for 90% of the webssite out there.
But my point was not to get the job done. It was to work towards one goal not seperate into a lot of goals.
But again thats just my opinion and point of view.
History will tell if I was wrong or not.
I'm on the cusp of this and couldn't agree more. I've recently switched all of my projects back to the simple html, css, and js. The only library I'm using is VueJS (but not the CLI). For development I literally just serve the
./app/folder. Then for production I use rollup to bundle everything and output to a./dist/folder.JavaScript has come a long way since all of these MVC frameworks started making waves and honestly it makes a lot of their functionality redundant. I only use VueJS over the others because it doesn't require a CLI.
There are even some added benefits of not having a watch/build step. For example you can utilize the built-in tools of Chrome/FF that allow you to directly change the CSS/JS in the browser and save it back to the folder. Or if you prefer the other way around, you can use VS Code's debugger to get breakpoints right in there. (Sourcemaps frequently break for me.)
I initially had some fears and do kinda miss things like nesting in SCSS but the general reaction while working with others in this environment is extremely positive. And we keep it clean just as well, if not better, than with a full framework/setup.
You should write a blog post about your work flow.
Drop me then a link to it
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.
Bold
Italics
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.¯\_(ツ)_/¯I think a lot of this is addressing problems that aren't really relevant anymore. Yes, it'd be nice if we could all come together and hold hands and agree on better standards for fundamental parts of front-end...but there's never going to be full agreement on what those standards are. And that's fine!
The modern front-end landscape benefits tremendously from the plethora of options available. It's not a one-size-fits-all world. Some developers may click with the "we are building serious apps here" approach of Angular, some maybe like the flexibility-with-first-party-support of Vue, and some people like me love how React gives you a start and says "go figure the rest out." And that's just the three big ones.
If you or your team is having issues choosing with the technology stack, and feeling overwhelmed, that's certainly valid - but it's also a fundamental part of software development, not something new or unique to front-end. Having all of these choices means having to need to be familiar with the pros and cons of each, and making an informed decision from there - this is an excellent skill to have as a developer. A necessary one, even. Note that this does not mean you have to be an expert in 50 different frameworks, that's a strawman that isn't remotely realistic.
Framework churn hasn't really been a thing for...years, now? Which is eternity in web dev time. The only notable framework that I've seen people thinking about jumping ship to is Svelte, and that's because it 1) does the technical bits differently and 2) offers a brilliant API. Long gone are the days of "ha ha JavaScript has a new framework every week."
This isn't even touching on how the browser itself is a problematic platform...because Google, and Apple on iOS, basically dictates everything. See Edge moving to Chromium. Until that elephant is addressed, the room isn't remotely equipped to deal with implementing agreed-upon standards that can be "free" of inordinate influence from one particular company.
All said - this is a great perspective on the importance of standards in general. We of course need them, and as mentioned we have some amazing ones via WC3, WCAG, and TC39. But I just don't think web components, as they exist today, are the solution, nor is the current framework landscape really much of a problem.
Standards come from standards bodies and are actual when implemented to a certain extent by multiple engine vendors... There's not much ambiguity in what the standards are. Try again.
Although I am a fresher in here, but this blog confused me in a good way, I am practicing Javascript to learn react for the same reason as you explained above, should I still go for react or is there any other programming language should I pursue??
1) ReactJS is not a programming language
2) Learn the basics of javascript
3) Learn the basics of html
4) Learn the basics of css
People will tell you no its okay to learn reactjs first. You can do that but in the history of coding frameworks would die after some time but the basics of HTML/CSS/JS are still the same as they were 20 years ago. Yes, they evolved and changed a little bit but still, they are the basis for every framework. It will also be easier for you to learn a new framework because they will build on the same fundaments
I feel nunjucks or other templating languages (like pug) are better. We can do what react and angular does and also we can dynamically include images/files from a folder with straight forward code which just pre-compiles with nodejs. Now, I am using react because of scss + css modules. Hopefully will try to come up with nodejs+nunjucks+webpack+scss+css modules soon.
I need to checkout nunjucks.
This is the first time I hear about it.
It is just a template engine library available to compile htmls with nodejs and on runtime. IMO, a huge advantage on react. This is not what web components does but can be combined with it to have full control of web development.
Sounds nice!
I 100% agree, I've been waiting for web components for far too long. I was hyping these up at work for years, then they seemed to have faded and finally came back again gaining traction. Web components are the next big game changer...
Yes! They are!
The problem is they are not baked by one big company!
So the community has to push them!
Obviously written by someone who has never worked on 100k+ line of code projects where everybody needs a beacon to rally around. In a perfect world there is one solution, in our world people like different things and different teams get along better with different frameworks.
Why do you assume I have never worked on a project that big?
Isn't this how languages and tools have come about? Multiple developers come up with their solutions, which inspire other, "better" ones. They take features from one another and eventually a winner emerges. Why rush a transition now? Maybe the solution should be you build your own framework designed to take the best features of these and address their weaknesses. Maybe that becomes the new standard.
A lot of good (useful?) options isn't a bad thing.
I'm not against having multiple opinions even with web components you would still have them.
It is more like today you could take the react-router and use it with vuejs and vice versa!
Maybe I'm also dreaming to much :)
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.
That's interesting point of view. After working for over three years in the javascript ecosystem i feel the fatigue myself. Honestly, what i feel is that most developers get distracted due to the shiny object syndrome. We tend to choose a technology primarily due to hype created around it and then spend a lot of time on things that don't matter (for the business).
For example, with ReactJs i've had a lot of problems with routing and middlewares. Using frameworks like redux also doesn't make things easier. Now i spend most of my time debugging frontend bugs rather than working on the critical business requirements.
It works fantastically when you're doing simple apps, but when it comes to building complex applications like ecommerce, or crm, i've been struggling with these frontend technologies. For me as an entrepreneur, spending more time on the frontend than on the backend is worthless.
I'm not sure about web components either, because as soon as it starts becoming popular, a lot of big players are going to jump into it and there'll be multiple (and most probably broken) implementations of the same components.
I'm not against these frontend frameworks and libraries, but again i'm not going to suggest these to my clients just because of their shiny appeal or hype. I personally only use python and flask to develop web apps and stick to simple templating engines. It's made my life easier. But that's just me.
Maybe web components are not the perfect solution right now.
But looking back at the history most of the time standards in the long run won over frameworks.
And yes using reactjs for a static website is a bad choice just to give one example.
I'm using yii framework with controllers, web components and modules. It's much safer, more stable and performs better than wordpress. Nevertheless I still feel bootstrap, jquery and a myriad of other libraries are necessary
Very interesting setup
I think the issue comes in to ways:
A company wants people in the same page, so they settle on one approach. This can be ok since most companies probably need one solution.
But a tech company should know many frameworks.
Then there's personal. I think it would take most devs a few years before having the experience required to differentiate and use the right framework for the right tools. And programming moves so fast, some options might no longer be relevant once you're ready
I agree fully with you.
I also think we as a community are following the hype to much.
dev.to itself is written in ruby on rails.
It does not need react hooks or agular X to work good.
It works fine with ruby on rails even if ruby on rails is not the newest hype!
Your article perfectly sums up what I believe the goal of the Aurelia JavaScript framework is. To abide by emerging and pre-existing browser standards, not invent new ones or ways of writing code (I am looking at you React and your JSX).
All frameworks and libraries should share the same goal: to eventually be replaceable by native API'S. But, let's be honest. React and Vue are so far removed from real JavaScript and HTML, that will never happen.
Concepts like the Virtual DOM (a glorified dirty checker), sound cool from a marketing perspective but are not as performant as developers make them out to be.
Sadly, the Web Components specification seems to be a mess. I have hope one day it will turn out as well as ES6 did. Until native API's and specifications align more with the requirements of modern front-end development, we'll continue to see these abstractions and bastardisations of the language continue to be popular.
"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. "
I believe React and Vue is not a framework. Also, if they solve common problems the problem, what's the problem with that? It's similar to design patterns solving common problems. It's well tested overtime.
I understand why we have all these frameworks, but I don't like it either. Whatever "correct" is, this wouldn't be so bad if everyone used them correctly. But the number of frameworks multiplies the ways to do things badly. Like when you encounter Angular with weird stuff hacked in where it didn't belong because someone didn't know any better.
It takes less effort to use something, but way more effort and experience to be able to look at code and recognize what's wrong so that you can fix it and avoid piling onto a mess.
I'm concerned that developers are learning just enough of one to make a giant mess, realize that it's out of control, blame the tool, move on the the next one, and repeat. Every time that happens they leave something behind that lives for years for someone else to come along and maintain.
That's my view of the problem, not a proposed solution. I'm leaning towards Blazor. Not that it's better, but because I've got a way better chance of looking at it and knowing what's right and what's wrong. In past experience I've also noticed that ASP.NET MVC code is slightly less likely to turn wild west than JavaScript, so I'm a little bit optimistic that I'll encounter less unmaintainable stuff.
While I fully understand the sentiments here, I think the article may have lost sight of WHY frameworks and libraries like Angular, Vue and React exist in the first place. I really love the idea of true open, complete standards. I can't wait for the day when we can build pure standard components, when PWA is the only kind of app, etc. Wonderful dreams! Lacking in reality, though, most of the time.
There are reasons why we have frameworks like Angular and Vue, though. Why we have libraries like Polymer and LitElement. To one degree or another, the core standards usually don't go quite far enough to really provide a complete solution that does not just solve a particular problem, but solve all the problems on the table, as well as support the infrastructure of validating them, deploying them, and keeping them maintainable, etc. They tend to lack opinions where opinions are useful, and often lead to "wild west" style projects that lack cohesion, consistency, etc. that can leave projects rather messy and unique (i.e. not easy for future developers, long term maintainers, to take on even if they have general experience in "Library/Standard X").
React in and of itself isn't even a framework. It is a library. And React itself is usually not enough to get the job done on its own. You will usually find other libraries glued together in a React product because of this shortcoming. Similar problems usually arise with "plain old web components", as they solve a problem, but are not a complete solution.
Angular gets a lot of rap from...many on the other side of one fence or another. The big thing Angular has going for it, though, is a consistent, reliable, and effective pattern for designing, building, deploying and maintaining simple apps through large scale, enterprise scale, applications. I think Vue is coming a long way down that road now as well.
These frameworks are complete solutions to business problems and the process of solving them, not just a solution to a particular problem inherent in leveraging the web as an applications platform. Components are a part of the machine, but not the whole machine itself. In real-world product development, we usually need The Whole Machine. ;) Further, that consistency and cohesion provided by a framework like Vue or Angular has solid benefits for long term projects that may move through many developer hands or many dev teams over their lifetime.
React, Vue and Angular are stepping stones and imperfect visions that brought components to developers in a cohesive way for the first time. I don't think the problem is we don't have the entire developer pool writing components for a unified compatable component scheme; that's not really how the web works. All of these frameworks already have robust calendar components out there, but everyone has a different functional requirement when it comes to actually implementing a component like a calendar that beyond the bare-bones, adding more features is only going to annoy people by bloating their code and project complexity. Even if we were all writing the exact same code, like in standard programming languages, you never see people really get together and build the "grand calendar" program, you have 500 and each operates differently in some specialized way. So while it may be odd we're all currently segregated into different libraries, it's promoted incredible progress and feature adoption that the web standard will need exponentially more time to implement. A standard underlying component structure is fine, disliking everyone working on various libraries is against the fundamental nature of an open-source community.
In the end all these frameworks are plain old javascript and HTML and CSS
The browser HTML rendering engine does not understand reactjs components.
It only understands simple dom manipulation.
So we technically already targeting one platform it is called HTML and JS
I think there's a good reason for why so many frameworks exist. It's rare to find developers that truly think/code the same way. A Java/C++ developer looks at JavaScript with disgust, but TypeScript makes sense to them. The same thing happens on the frontend.. Angular makes sense to those of us that have been with it since the beginning, but we look at React and get headaches trying to figure it out. However, VueJS not so much, it's a simpler way to do what Angular can do, without all the drama.
Newer developers don't seem to have an issue with writing HTML inside javascript code blocks, and so they lean towards React. Those people clearly dip their chocolate chip cookies in the Ketchup. But hey, to each their own.
At the end of the day, you go with the method/framework that you can wrap your head around, without making you look like a fool.
When I started web development you would be in the hall of shame if you would mix HTML and js and CSS.
It was an anti-pattern.
I still think JSX is not the right way to go.
That's why I like for example sveltejs more.
And yes everybody should use whatever he or she likes!
Ever since I heard about Web Components V0 I was VERY excited. But the support was limited to Chrome. This year (and maybe last year) it really started to hit other browsers.
Excited times to be a web developers.
You should be asking a different question. It’s like the question of it you should work hard or if you should work smart...
I don’t know about you, but I work both.
And when it comes to learning Angular or React, the same is true. If making the outcome of the decision between the two is important to you, if you don’t learn both you’re just being lazy.
Take an afternoon and run through the hello world tutorials for both React
and Angular and you’ll get a whole lot more context of what each is doing.
Then, you can make an informed decision based on the aspects of the framework instead of using silly metrics that don’t matter like number of cream chargers searches, etc
i actually find alot more information here. You clearly know nothing about angular. : cream chargers
I agree on this. There is no need to have any framework. Javascript/jQuery is powerful enough to make code with least possible easy to understand way. Browser understand only Javascript, CSS and HTML. I have used AngularJs, React too, which make things more complicated, more amount of code to write, many common things not available. They change things pretty soon and time wasted on catching up with changes is huge. Code of angular and react kind of framework is more complicated and difficult to understand. HTML, JavaScript and CSS was designed by genius developers to keep things simple, easy to understand and debug.
How things are moving. Many developers in IT industry lack that level of IQ and common sense. Some of them make some useless crap to get attention within an organisation, which are mostly run by non technical herd of MBAs. They showcase that to higher authority, which again is no technical. That crap is adopted and forced upon rest of the engineers. That crap becomes a prestige and engineers start showcasing that as a skill. Now when any business who has no idea about technical details hires one of such guys as IT consultant, who show his intellectual and suggest using that crap framework for fucture development.
I had written a small Javascript library to do common tasks in an application
All that took me just 3 months to write, implement and test. I now repeatedly use it with HTML-5 markup, which is very small and easy to understand.
I don't know why we needed these frameworks in first place, when any developer could write reusable javascript functions for common tasks in the company and all could use it. HTML-5 data- attribute is so powerful, that we don't need any fancy framework now.
You do you, but there's a definite place for frameworks and UI + Component libraries, otherwise they wouldn't still exist.
If I move company, from one Angular codebase to another Angular codebase, I'm going to know how to debug the new codebase, I'm going to know the general structure and location of files, I'm going to know how the code is built and served.
In other words, there's less time required to onboard me.
React codebases aren't as uniformly structured like Angular ones are, but I am still going to know a consistent way of creating and maintaining the components.
Those points stand for Vue too.
Next, there are tons of documentation and question+answers on these frameworks out there. If we hit a problem, there's places we can look to get help.
If you develop a custom unique library at your company, there won't be the same level of documentation, if developers come and go, knowledge for that custom library deteriorates and it becomes more difficult to maintain.
A lot of these frameworks and libraries focus on performance and developer experience, which are huge factors. Can you guarantee that from the code you've written?
Also, a lot of these frameworks and libraries come with the solutions you mentioned above out of the box. Developers save time by not having to rewrite them, and they have documentation surviving on the internet to look back to if they need to understand what's going on.
Can you also guarantee the security of your own code versus a third party who had a priority to ensure security?
What a great article (and huge polemic), I can't wait to see the next one.
I love the easy things these frameworks/libraries provide but yeah, I would like to get rid of them and stay on an "official" path.
I am a UI developer and not that much a front end engineer, so I don't go too much in depth with the algorithms, but I must know some basics. I love Vue because, with Vue CLI 3, it provides many things super fast.
I have some questions:
1) About Polymer:
A) I tried Polymer may be 2 years ago and I couldn't succeed in using it. I also saw its popularity didn't go that high (too bad, because I loved the concept), is it a library you people would recommend to use?
B) Polymer, if I understood, is simply a library of web components with a design based on Material? So using Polymer is the same as using web components from webcomponents.org ?
3) When I use Vue, I love to use:
A) SPA/router: Is it easy to create a SPA and router in vanillaJS?
B) Compilation: should we use webpack or any packaging tool like Vue does?
C) loop in HTML (v-for): is it easy to replicate such thing in vanilla JS?
4) People look like to love Typescript. At my level, I hate it. Because this topic talks about replacing frameworks I thought it might go into the same box. May be JS will integrate types in a future revolution update, but for now, it looks to me like something that comes and one day will go too.
Thanks!
No it's not. We've been developing app using Vue + web-components wrapper and it was pretty bad. Some of the used libraries wasn't working. Different behaviour in IE11 of different versions and some other problems I don't remember about. Eventually we removed web-components wrapper and it became much easier for everyone. Not going to write a big comment article/comment about it, so you can either trust me or not, up to you :)
A very entertaining and well written article. The picture is particularly funny.
The problem with the latest frameworks is that they are based on the same flawed paradigm. That flawed paradigm being that, in the majority of use cases, it makes sense to bury your html in javascript and cache it all on the browser. I don't think I have to make a case about how much more intuitive it is to render your html on the server, slide in some dynamic data and then send it to the browser. There is a reason that ROR, PHP, and Spring MVC, are still alive and kicking. Of course you can still use javascript components to your hearts content browser side to make your web page feel like a destktop application, even when the HTML was rendered server side. Furthermore, Ajax calls remove the requirement to refresh the entire page. The short story is that React is absolutely necessary for a huge mosaic page like Facebook, but for your standard airline, car rental company, or bank account web application it is massive overkill. It adds a lot complication to a web application that could be maintained by a group of high school sophmores in a server side paradigm. Web application development does not need to be this complicated!
Here is rundown I made of recent choices and pros and cons dev.to/matthewekeller/web-applicat...
I believe that the technologies being developed for Angular/React/etc should be incorporated into regular web technologies with efforts from W3C ofcourse. Just like innovations from app developers sometimes end up being adopted by the OS itself.
I think it's time for HTML6, where things like string interpolation, property binding, two way data binding, etc would be standardized.
JavaScript ESNext should bring in native support for building components, routing, dependancy injection and so on.
Hmm. I'm not sure how strong marketing for either framework is but doesn't easier uptake/low learning curve just make frameworks easier for devs to adopt? Maybe by default how many moving parts angularJS had gave react a leg up, and the total revamp of ng2 alienated too many? I also think maybe there's a lock in happening with preferring class based vs functional components... Until you have clear evidence they're paying off bootcamps and tech schools ill remain skeptical...
I think WebComponents are just the UI part of the web apps and they are more comparable to React than any framework. We will still need to have libraries for other SPA needs such as routing etc just like React.
Plus lets imagine we all start using WebComponents, we will need to put reusable components in some libraries. Eventually we will end up with lots of proprietary libraries or people will start building open source WebComponents UI libraries and we will be back at the same issue you are trying to resolve.
In fact at the moment there are many open source WebComponents packages avaliable. If you think people will agree on one package and they will start developing that instead of creating a new, I believe it will not going happen. Have a look at this blog.bitsrc.io/9-web-component-ui-...
Although I agree with the issue you are trying to solve and I am not in favour of many frameworks myself unless they are necessary. Mainly because of the fragmentation reason and also I want to have more control over what I am building. We should also learn how to create things and not just how to use things which other people have created.
Amen my friend!
🤟😀🙌
I rarely have to do something else. What does this have to do with how to write the actual code? When I hear such a statement from a developer in my team, it means they are going to cut corners and they are going make a hard time for the others.
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 😄🙌
Can anyone provide a base code example so I can see the structure for an optimal 2019 build?
Any GitHub sources which I can reference to clone for my new project would be appreciated.
As a on off developer what I find hard is that there is so much breadth of methodologies now a days.
What is the optimal build architecture?
Just use reactjs and don’t use angularjs?
My last project a few years ago was build on meteors. Any views on this stack?
The only way to end up with really great tools, is by competition. Therefore it's important to let everyone do their own thing, that's what's pushing us to do better.
I don't think that this really works in all cases.
Too much competition can be as bad as no competition.
Video game market crash in the '80s for example.
"Year of the Linux desktop" is a meme by now.
I agreed with you sir.
Thank you very much 😊 🙏
Good read. You make some great points. I've always felt fragmentation is an issue within the development community. There are certainly pros and cons to having so many options to choose from.
Like with everything in life!
I just see the same thing happening in the world of Linux desktops and it does not help Linux desktops to have so many options
Really interesting post, can't wait for part two. Also I'd say that while over-fragmentation is bad, having only one solution can also be bad.
That linux comic tho 😂
Yes and Yes!
There still can be more than one web component framework but at least I could use my react-router in my vue component!
Vue CLI currently supports webcomponent as a build target.
cli.vuejs.org/guide/build-targets....
vuejsdevelopers.com/2018/05/21/vue...
This is fantastic!
I did not know this!
This is what I mean!
Have web components as a build target!
Thank you very much!
I remember my ex-manager who left to work as a developer, He said these words last year. And then we started using polymer and litelement. We use those two frameworks mixed.
Nice can you share a little bit about your experience?
I've been saying this for a while: mobile.twitter.com/fmontes/status/...
Glad I'm not the only one :)
Nice!
I see it the same way!
Relevant XKCD
xkcd.com/927/
Replace the word with frameworks in that XKCD and you have the javascript community in a nutshell!
So much truth herein.
In the end it is just my opinion and what I have seen over 10+ years of web development
Really , is that what you have to say!!! Funny!
Call me joker 🤣😂🤣
In your argument here you are missing the key part: development cycle, managing code changes and debugging.
I wish you good luck to develop an enterprise app only with vanilla js, css and html5.
It is not impossible, i did it for several years in my early development days, i still like it because of the power it gives you, but you simply can not compete with someone using frameworks.
For example, angular cli, generates files for you with minimum code, you separate templates from actual code and styling, it automatically creates a minified dist folder to publish while your code is structured into meaningful folders.
Let's take typescript as another example - it made web development easy to backend-focused developers. It improves code readability and minimizes code mistakes which you could easily do in plain js.
I agree, frameworks should compile to whatever is native and the trend is to do so.
Jquery has died because it had its limitations + the best part of it - css selectors - are now implemented natively in browsers; and how many of us are using them directly now? None. Why? They are implemented in each of the targeted frameworks in your post.
To sum up, for sure web components will be targeted soon by frameworks. That's a fact. But in the foreseen future, the frameworks are here to stay for how they speed-up development process.
Yesterday we had nokia 3310 and pc, now have smartphones with android and ios, tablets, talking cars, talking homes and what not.
Future and evolution is all about implementing new ideas and getting your head out of the standard box; as long as we accept that each of us is different, we accept different tools and technologies to choose from.
Fight for your life - climate justice!
Great Post
I'd argue that to focus on concrete problem, you have to start with concrete problems and look for simplest solutions.
This is why I wrote this:
github.com/dmitriz/un
You've nailed it.
I want to believe! :)
How would you do data binding without inadvertently recreating your own tiny framework?
With lit-html. It's a wrapper around JS template literals, the native dom, and the html5 template tag, which allows you to define dom snippets that don't get fully instantiated, only stubbed. Basically you get syntax similar to JSX but lightyears more performant. You just need to kick lit-html to update the stamped segment of the dom whenever the attributeChanged() observer runs. This is a watered down version of what lit-element does. Heck I've seen someone extend lit-html to support Angular syntax and plug it into lit-element as a modular replacement template engine.
Is that a micro-framework? No, because the component model, data model, and templating model are almost entirely defined based on the existing html, css, js, and dom-api specifications and interface guarantees. The browser becomes the framework, just as it already is a framework for w3c compliant native html nodes. All a library like lit-element, or stenciljs, or lightning-element do is encapsulate the boilerplate of the native api's.
@Iampewebdev Bold article! I share your views. We should move on. Web Components are the future. But it is time-consuming to drag along the community towards that goal. We will reach there eventually.
Let me stop you right there.
Your post looks exactly like "I'm a developer hat and want to use the new fancy shit" as you said in the article. You just use "web components" yada-yada instead of "<put your framework here".
I like how none of the problems mentioned about Reactjs apply to Vue
Whats your opinion on svelte?
Totally agree.
Glad that you forgot to mention that safari has decided to not support html imports.
Can you explain what is not good about it?
EHTML solves the problem that's described in the article: github.com/Guseyn/EHTML
That looks like exactly the same thing to me.
... but it replaces Javascript with its own language. It's irrelevant whether some of that language takes the form of tags.
"I want to solve real problems and give people solutions they really need" -this hit me hard lol
You have to start at some point right?
And I rather contribute to a standard than a framework that will be legacy in 3 4 years.
I think, we should not run after the technologies just because they are backed by Big Companies. Rather, we should try to solve a real world problem using best possible technical solution.