There are so many things to discuss on this chapter, things got crazy in the last 5 years.
the ecosystem got a huge infusion (as %) of new developers that jumped directly to frameworks skipping Computer Science, OOP and vanilla JS
the frameworks got more and more abstract
the base JS/CSS problems are getting fixed by the users not by the ECMAScript, browsers and others
And now we reached a stage where
"react devs" do not realize that that "Shadow DOM" are actually JS objects and "redux reducers" are actually plain functions.
for a simple boilerplate I had to get a few frameworks that downloaded 1300 NPM packages (webpack, react, SCSS, Babel, JSlint)
Even the fact that the expression "vanilla JS" exists states that the ecosystem has a huge identity issue.
But ... this statement has 2 sides
We can't hire someone so tightly bound to a technology, it is too restricting and not future-proof.
This means your company will develop its own methodologies and styles, which probably are not found anywhere else. The company and the devs will have to lose resources (devs will learn these, and cannot reuse that knowledge), lose-lose.
if we wanted to build a huge and complex multi-engineer project then a framework might be necessary
If the company developed more then a few of (100s files) websites you already built another framework.
"react devs" do not realize that that "Shadow DOM" are actually JS objects and "redux reducers" are actually plain functions.
I have a hard time with this sort of statement; seems like a difficult one to measure. I know lots of devs that are very aware that reducers are plain functions. I also know lots of devs that know precisely zero about the shadow DOM, because React means that they don't have to.
This means your company will develop its own methodologies and styles, which probably are not found anywhere else. The company and the devs will have to lose resources (devs will learn these, and cannot reuse that knowledge), lose-lose.
Absolutely agree with this - using libraries like React and Redux in my workplace have made it much easier to ensure all devs are on the same page, and most issues are pretty trivial to find answers about.
I tend to agree with the view that if your code reached a level of complexity where you begin to develop your own framework, then you should just use an existing one.
Hopefully the knowledge gained getting to this point also means you now know enough to pick the right one!
When you reach that stage there is no going back to a framework, the change would be too costly with minimal ROI. Its a decision you should make before writing code.
There are so many things to discuss on this chapter, things got crazy in the last 5 years.
And now we reached a stage where
Even the fact that the expression "vanilla JS" exists states that the ecosystem has a huge identity issue.
But ... this statement has 2 sides
This means your company will develop its own methodologies and styles, which probably are not found anywhere else. The company and the devs will have to lose resources (devs will learn these, and cannot reuse that knowledge), lose-lose.
If the company developed more then a few of (100s files) websites you already built another framework.
I have a hard time with this sort of statement; seems like a difficult one to measure. I know lots of devs that are very aware that reducers are plain functions. I also know lots of devs that know precisely zero about the shadow DOM, because React means that they don't have to.
Absolutely agree with this - using libraries like React and Redux in my workplace have made it much easier to ensure all devs are on the same page, and most issues are pretty trivial to find answers about.
I tend to agree with the view that if your code reached a level of complexity where you begin to develop your own framework, then you should just use an existing one.
Hopefully the knowledge gained getting to this point also means you now know enough to pick the right one!
When you reach that stage there is no going back to a framework, the change would be too costly with minimal ROI. Its a decision you should make before writing code.
Which is fine when you already know why you want to choose a particular framework and that it will do the job you need.
I also hate being locked in to an approach which means your future options may be constrained.
There may be benefit in us refactoring as a training process and because the early apps really have some weaknesses!
But I get your point, maybe in the end we'll just switch to "the final solution" for the next iteration of development.