There are indeed situations where it's sensible not to use libraries or frameworks, but those situations are rare and should only ever be touched upon by experienced senior developers. If I gave the code presented in this blog post to most of my colleagues I can guarantee that within a couple of months it will be completely and utterly unmaintainable. I am not sure I would be able to keep this code clean. This reminds me of the messes we had 10+ years ago.
If anything I think this blog post represents the trap most passionate (and often inexperienced) developers fall in (including me). We hate the overhead of libraries and/or think we can do better. It's good to reinvent the wheel once every while, because it's possible to improve, but we shouldn't reinvent the wheel ever single time we build a car. If the goal is to make private components for a project with a strong data pressure forget about web components and pick any library in the react-style (be careful with your transpilation settings). If you don't care about the amount of data go for a library in the angular-style. And if the component should be used by lots of people go for web components (including huge polyfill), or if the data thing is a huge problem make it a backend rendered component (yes, there is still a place for those).
The only thing you should never do (professionally) is go at it vanilla. There is nothing inheritly better about vanilla. Vanilla is just the set of base libraries decided upon by a small group of people. What's important is to pick the right set of tools. I mean, I get how tempting vanilla is and sometimes it can be the right set of tools if the requirements are extreme enough. Years ago I build a private application that actually performed and looked like native on mobile when that claim was still just an empty promise. The cost was that it was 100% unmaintainable.
Point is, I don't think you are doing anybody a favor with a post like this. It will just put more inexperience developers on the wrong path.
David couldn’t agree with you more.
Code Maintainabilty is the most underrated thing in the world. While doing something like making a fancy vanilla Javascript is cool and will get you some pat on the back, it is not pragmatic and I doubt you would ever use beyond more than a blog post example.
I agree that Vanilla component is a wrong and amateur idea, but, my friend, I think you are too fond of using frameworks, and that is much greater threat to your projects and your career.
I have 14+ years of experience and was a heavy framework user once, but now I only have ReactJS and NodeJS in my toolbox. Most frameworks today are created by amateurs that dont know how to solve problems in a simpler way, and promoted/adopted by a huge community of amateurs who know no better but love to make noise.
Don't start with questioning my skills or capabilities, I finishes hundreds of man month effort in days
r/reactjs, r/programming, r/javascript :) No post in particular but it would be fun to watch as your comment gets downvoted into oblivion.
Do you really think that Facebook's React team and Google's Angular team are made of amateurs? Lol
Ha ha. That should be fun. I would love to see it too. Pretty sure it will happen. About Angular and React team, I dont think they are amateurs, but still, our definition of amateur are very different
I think frameworks work very well in software focused small to medium sized companies that can scope out there technological future very well, and can cultivate teams experienced in the framework that fits their scenario. However, imagine a scenario where you are working on something for a very large non-software focused company. You can't introduce a framework as the scope of the work is too small to make such long lasting decisions. You also want to build something that is still relevant 5 years down the line. You don't know who will be working on it or what there expertise will be. The platform stays relevant forever, frameworks do not. However like I said, frameworks provide an amazing benefit when used in an organizations that, you might say, respects their power.
So I think we might see eye to eye on this, if provided a specific scenario to problem solve for. However the only thing I would really take issue with is maintainability. If certain rules are followed in regards to what code is responsible for what, then this is certainly maintainable. JavaScript by it's nature has always been poor at enforcing separation of concerns, leaving it up to self governance from the developers. Luckily this is changing in updates to the language and web components.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
There are indeed situations where it's sensible not to use libraries or frameworks, but those situations are rare and should only ever be touched upon by experienced senior developers. If I gave the code presented in this blog post to most of my colleagues I can guarantee that within a couple of months it will be completely and utterly unmaintainable. I am not sure I would be able to keep this code clean. This reminds me of the messes we had 10+ years ago.
If anything I think this blog post represents the trap most passionate (and often inexperienced) developers fall in (including me). We hate the overhead of libraries and/or think we can do better. It's good to reinvent the wheel once every while, because it's possible to improve, but we shouldn't reinvent the wheel ever single time we build a car. If the goal is to make private components for a project with a strong data pressure forget about web components and pick any library in the react-style (be careful with your transpilation settings). If you don't care about the amount of data go for a library in the angular-style. And if the component should be used by lots of people go for web components (including huge polyfill), or if the data thing is a huge problem make it a backend rendered component (yes, there is still a place for those).
The only thing you should never do (professionally) is go at it vanilla. There is nothing inheritly better about vanilla. Vanilla is just the set of base libraries decided upon by a small group of people. What's important is to pick the right set of tools. I mean, I get how tempting vanilla is and sometimes it can be the right set of tools if the requirements are extreme enough. Years ago I build a private application that actually performed and looked like native on mobile when that claim was still just an empty promise. The cost was that it was 100% unmaintainable.
Point is, I don't think you are doing anybody a favor with a post like this. It will just put more inexperience developers on the wrong path.
David couldn’t agree with you more.
Code Maintainabilty is the most underrated thing in the world. While doing something like making a fancy vanilla Javascript is cool and will get you some pat on the back, it is not pragmatic and I doubt you would ever use beyond more than a blog post example.
I agree that Vanilla component is a wrong and amateur idea, but, my friend, I think you are too fond of using frameworks, and that is much greater threat to your projects and your career.
I have 14+ years of experience and was a heavy framework user once, but now I only have ReactJS and NodeJS in my toolbox. Most frameworks today are created by amateurs that dont know how to solve problems in a simpler way, and promoted/adopted by a huge community of amateurs who know no better but love to make noise.
Don't start with questioning my skills or capabilities, I finishes hundreds of man month effort in days
I would love to see your comment on reddit :)
Sorry, but I don't know what you mean, I which reddit post?
r/reactjs, r/programming, r/javascript :) No post in particular but it would be fun to watch as your comment gets downvoted into oblivion.
Do you really think that Facebook's React team and Google's Angular team are made of amateurs? Lol
Ha ha. That should be fun. I would love to see it too. Pretty sure it will happen. About Angular and React team, I dont think they are amateurs, but still, our definition of amateur are very different
I think frameworks work very well in software focused small to medium sized companies that can scope out there technological future very well, and can cultivate teams experienced in the framework that fits their scenario. However, imagine a scenario where you are working on something for a very large non-software focused company. You can't introduce a framework as the scope of the work is too small to make such long lasting decisions. You also want to build something that is still relevant 5 years down the line. You don't know who will be working on it or what there expertise will be. The platform stays relevant forever, frameworks do not. However like I said, frameworks provide an amazing benefit when used in an organizations that, you might say, respects their power.
So I think we might see eye to eye on this, if provided a specific scenario to problem solve for. However the only thing I would really take issue with is maintainability. If certain rules are followed in regards to what code is responsible for what, then this is certainly maintainable. JavaScript by it's nature has always been poor at enforcing separation of concerns, leaving it up to self governance from the developers. Luckily this is changing in updates to the language and web components.