It's exactly as you say. There is no such thing as as a tool suited to everyone and every use case. Each is good at certain things and sacrifice certain other things.
One of the more irritating things, I think, that so-called "modern" front end developers are missing about the "traditional" separation of concerns between JavaScript, HTML, and CSS is that each language is, in fact, designed for and suited to certain concerns that DO change independently of each other in a UI. And some of those concerns (particularly the semantics and presentation) need to be contributed to by designers, copywriters, accessibility experts, etc. It is neither scalable nor egalitarian to make everything go through traditional programmers as gatekeepers.
Somewhere along the way, people got so fed up with HTML in particular not keeping up with providing for what was being repeatedly built that they decided the big problem was that separation of concerns existing instead of components that combined all three. The former is understandable and the latter isn't wrong, but it's not the complete picture, either. Just look at what's happening in those frameworks over the course of only a few years: that scoffed-at separation of concerns is being reinvented in various non-standard ways.
But in the meantime, several generations of developers have been taught nothing but frameworks and scorn for the web platform. Who would, in this climate, be willing to take the risk of leading evolution in the platform?
The JavaScript framework community in particular likes to play the victim about this. Oh, the web gatekeepers made fun of React as spaghetti code and said it would never work. All the while apparently oblivious to their own hypocrisy given their own disdainful attitudes toward the work-in-progress of the web. In full view of and often aimed at living people who were still working to solve the very problems the framework devs were anxious about.
The one no-go thing for the platform is doing away with HTML and CSS and doing everything with JavaScript. For dozens of reasons published about endlessly over the last 30 years and easily learned unless you're the type of person who thinks they know everything already. But, no, surely the platform developers were out of touch fat cats and the framework developers were the wunderkind. Framework developers were not making any trade-offs inappropriate for the platform level at all, no sir! People eat this crap up and I'm sick to death of it, as you can surely tell.
But these frameworks could make web development better. They already have for many people. That's just a fact. But they're short term solutions that need to make their way into the platform in a way that works in the platform. That's good for everyone, especially users.
I actually blame technology marketing for this problem the most! Developer evangelism is a worthy cause, but it's also led to everyone talking like every tool is the next Coming of Jesus. That's good for no one.
I think open source frameworks and libraries are a place to experiment with and mature ideas that will improve the platform. I also think they'll always exist, because there will always be new things we need after addressing the last batch. On top of that, I don't think everything can be provided for by the platform. There are all kinds of niches and domains that need attention and tools that wouldn't make sense for the platform. Not to mention people just have different preferences in developer experiences.
An issue as I see it is that it seems the majority of developers aren't great at figuring out which side of that line something is on. Or if not that, at approximating something that could translate more straightforwardly into one. It seems common to get caught up in the abstraction layer on top of the platform.
This is something browser vendors and web standards organizations should really focus on. It should be easier to learn what kinds of things could work, to pitch those ideas, to get actionable feedback, and so on.
As of now the very people that are most needed are alienated from making those contributions. I agree it's what's needed, but how does the industry get there from here?
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.
It's exactly as you say. There is no such thing as as a tool suited to everyone and every use case. Each is good at certain things and sacrifice certain other things.
One of the more irritating things, I think, that so-called "modern" front end developers are missing about the "traditional" separation of concerns between JavaScript, HTML, and CSS is that each language is, in fact, designed for and suited to certain concerns that DO change independently of each other in a UI. And some of those concerns (particularly the semantics and presentation) need to be contributed to by designers, copywriters, accessibility experts, etc. It is neither scalable nor egalitarian to make everything go through traditional programmers as gatekeepers.
Somewhere along the way, people got so fed up with HTML in particular not keeping up with providing for what was being repeatedly built that they decided the big problem was that separation of concerns existing instead of components that combined all three. The former is understandable and the latter isn't wrong, but it's not the complete picture, either. Just look at what's happening in those frameworks over the course of only a few years: that scoffed-at separation of concerns is being reinvented in various non-standard ways.
But in the meantime, several generations of developers have been taught nothing but frameworks and scorn for the web platform. Who would, in this climate, be willing to take the risk of leading evolution in the platform?
The JavaScript framework community in particular likes to play the victim about this. Oh, the web gatekeepers made fun of React as spaghetti code and said it would never work. All the while apparently oblivious to their own hypocrisy given their own disdainful attitudes toward the work-in-progress of the web. In full view of and often aimed at living people who were still working to solve the very problems the framework devs were anxious about.
The one no-go thing for the platform is doing away with HTML and CSS and doing everything with JavaScript. For dozens of reasons published about endlessly over the last 30 years and easily learned unless you're the type of person who thinks they know everything already. But, no, surely the platform developers were out of touch fat cats and the framework developers were the wunderkind. Framework developers were not making any trade-offs inappropriate for the platform level at all, no sir! People eat this crap up and I'm sick to death of it, as you can surely tell.
But these frameworks could make web development better. They already have for many people. That's just a fact. But they're short term solutions that need to make their way into the platform in a way that works in the platform. That's good for everyone, especially users.
I actually blame technology marketing for this problem the most! Developer evangelism is a worthy cause, but it's also led to everyone talking like every tool is the next Coming of Jesus. That's good for no one.
instead of advocating for framework people should focus in making the platform better and more suitable for making apps.
Payments Api, Service Worker, Push Notification, Add to homescreen are good features that aim to make the platform better.
I think open source frameworks and libraries are a place to experiment with and mature ideas that will improve the platform. I also think they'll always exist, because there will always be new things we need after addressing the last batch. On top of that, I don't think everything can be provided for by the platform. There are all kinds of niches and domains that need attention and tools that wouldn't make sense for the platform. Not to mention people just have different preferences in developer experiences.
An issue as I see it is that it seems the majority of developers aren't great at figuring out which side of that line something is on. Or if not that, at approximating something that could translate more straightforwardly into one. It seems common to get caught up in the abstraction layer on top of the platform.
This is something browser vendors and web standards organizations should really focus on. It should be easier to learn what kinds of things could work, to pitch those ideas, to get actionable feedback, and so on.
As of now the very people that are most needed are alienated from making those contributions. I agree it's what's needed, but how does the industry get there from here?