By 2019 we all agree that components are the way to build fast, elegant and maintainable UI's. The problem is that every framework, like ReactJs, Angular(JS), VueJs, or some other smaller UI framework, uses its own patterns and solutions to common issues. These frameworks promote reusability and that they are easy to use. Also, one point I hear often is that they are mostly backed by big companies, like Google or Facebook. Let's have a discussion if this is really true, if maybe the community could do better and if there perhaps is a better alternative.
Web development is in a unique position. Web site, Web Applications, PWA's or whatever you want to call them are running in a browser, and in the end, it is all HTML, CSS, and Javascript ( and maybe Web Assembly). The goal then should be to use these tools most proficiently possible. I don't mean by that to use all of them without any kind of library or framework. You should use them, but what happens if we have too many to choose from? Overchoice happens! You are paralyzed because you have too much to chose from. Instead of being fast, you are slow because you don't know what frontend UI library to go with.
Okay, you now think: "I will go with reactjs every time.". This can be one solution. It can be a perfectly fine solution but still Angular, and the other UI frameworks still exist. This means that instead of working together as a community, we are fragmenting ourselves into these small communities. It gets even worse when you look that most of these tools are lacking features that we use daily. Routing in ReactJS is not fun at all. Form validation is also not fun and something nobody wants to do. So people need to create libs again for these UI frameworks, and there are most of the time like 2 or 3 libs to do these things. Not only we split our efforts into these groups of UI frameworks in these groups, but we also cut our efforts again to reinvent the wheel. Just think about the working hours we as a community have wasted here?
I can see people now think, but this is a good thing! Is it really? Please google: "Year of the Linux desktop.". Desktop Linux has the same problem. Gnome, KDE, XFCE, Cinnamon, Mate, LXDE, and man more. They all try to solve one thing: Make Linux better on the Desktop. Are they succeeding? You tell me down below in the comments.
Next point is reusability. Does someone remember the jump from Angular 1 to Angular 2? Yeah, it was like a completely different framework. Now we have Angular, and AngularJS which is not confusing at all. You now think, "but wait! Reactjs does not have breaking changes". You are right; they had no implicit changes like react v1 and react v2! I dare you to try to post react code where you are not using hooks! Half of the comments will be about "why are you not using hooks???". The same happened when you had to rewrite your react code from class-based components to function based components. Now I ask you a question where you have to be honest to your self and take down the "I'm a developer hat and want to use the new fancy shit" and put on the "I want to solve real problems and give people solutions they really need.". Did any of these changes really give any value to your customers? To your users? To your business? Is your code really now more comfortable to read? If you are really honest to yourself, then you would probably still be happy with class-based components. I think we can now say that maybe we have been tricked by marketing?
Wait, what? What has marketing to do with this? See people tend to forget. Who created ReactJS? Facebook, and who created AngularJS? Google. What are these companies known for? If you now say a social network and internet search then again you have the wrong hat on! They are known for advertising and marketing! If you want to know what a company is really doing is not to look at there products but how they make money.
The tail of "It is backed by a big company, so it has to be good.". I hear this so often without the person even having thought about it for longer than 1 second. This sentence promises that just because a company with a lot of money is behind the framework you are using will not go away one day. Google is famous for killing projects. There is even a website for this: https://killedbygoogle.com/. Still, want to use Angular? Okay but what about facebook? Facebook uses reactjs for a lot of projects. They are also looking for new enginers all the time and wouldn't it be efficient if the person joining your team would already know the framework lib you are using? This is something you have to decide for yourself.
I hope you now see some of the problems that we are having right now in the web development community.
How can we fix this? I personally think we already have the right way of fixing all of these problems. Standards! Yes, correct standards! The W3C is an excellent consortium, and more people from the community should be involved there. But this is a topic for another blog post.
Why do standards help us with all the issues?
When a technology becomes a standard, all major browser already have it implemented and ready to use. So this means that I, as a developer, don't need an extra library and I don't need to think about edge cases in a different browser. If there are bugs or problems, then it is in the responsibility to fix this bug for all its users. So it is in one hand to fix it not in thousands of developers hands. It would also help with the fragmentation of the community. What if you could write one component and use it in VueJS, Angular and ReactJS? Wouldn't that be fantastic? So more developer could work on one Calendar component and make it an excellent component instead of having 20 half bakes calendar components? What if all of this would happen without one big company backing this up? Instead, we as a community and all browser vendors?
What if all of this happened and we forgot?
Yes, we! The technology is called "Web Components v1".
Back in 2014, there was a big discussion if we as a community should go with web components or ReactJS. As you now know, we decided to got with ReactJS. At that point in time, it was maybe the right choice because web components were too young and the spec was not ready. That's why we call them web components v0 and we now have v1 since 2018. Now, all big players accepted this spec and have implemented it except edge (of course). Also, there are polyfills for older browsers.
So how do you use them, and how do you integrate them into your current projects?
We will discuss this next week since this blog post is already very long. See this one more as discussion and feel free to comment down below!
👋Say Hallo! Instagram | Twitter | LinkedIn | Medium | Twitch | YouTube
Latest comments (248)
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...
Great Post
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?
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...
Let me stop you right there.
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.
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?
"I want to solve real problems and give people solutions they really need" -this hit me hard lol
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.
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.
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.
Glad that you forgot to mention that safari has decided to not support html imports.
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.
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.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.