If I had to pick a single pain point about front-end development right now, it would be this. The new features in HTML, CSS, and native browser APIs plus the variations and limitations of each browser (plus the special and not particularly settled world of mobile/tablets) is hard enough to keep up with.
But we're now in the stage where there's a dozen frameworks out there, probably classifiable into at least three distinct paradigms, and then we have the languages that target the browser. And I suspect we're a long way from shaking this out into a semi-stable point.
The thing that I like least about this treadmill is that time invested in the ephemeral arcana of a stack/platform is time that isn't invested in skills that will transfer elsewhere and help you become a better general problem solver.
The cambrian-explosion of frontend frameworks you mean is mostly about patching up the web browser to do something it wasn't born to do though. The endless cycle of solving things that are solved elsewhere won't stop as long as the browser keeps being pushed as an application platform.
That's a rather negative take on it. I'd argue instead that the explosion in frameworks is a result of a broad interest in developing and experimenting with new approaches to providing applications. Web applications are typically network-aware, real-time, cross-platform and easily-updated; the basic technologies (HTML, CSS and Javascript) are easy to start using, and in some ways extraordinarily flexible.
I don't think that these are actually solved problems, and the web as an application platform can play a part in changing that.
Further, the whole concept of "patching up" a platform to "do something it wasn't born to do" is misleading. Every computing device you use has it's roots in older software that was developed without being intended to perform the tasks it currently is - we stand on the shoulders of giants.
The web as an application platform is still in its infancy, and we're currently playing around with a lot of different approaches - some will live, and some will die. It's how we make progress, after all.
I agree that's a rather negative take on it, but I can't help. Working on web development for almost 15 years has washed away my sugarcoat ;)
Frontend web development is still absolutely painful and ugly. It's based on a broken paradigm (hypertext vs. interactive interfaces); relies on hacks for fundamentals (XMLHttpRequest is probably the best example); multiple standards pushed by organizations with special interests (remember having to encode video in 4 different formats?); is labour and time-intensive; tooling is still catching up with the 80's.
None of those, in isolation, are big problems though. The big problem is that, because you can always patch everything up with some javascript, there's no drive to have a platform that rests on top of more sound fundamentals - condemning ourselves to an endless cycle of frameworks.
> the browser keeps being pushed as an application platform
Grumpy nitpick. The browser-as-platform hasn't been so much pushed on the rest of us, as if by some narrow conspiracy. It's been pulled along by mass economic force. Its ubiquity, extensive reach across OSes and devices, and freedom both in terms of beer and speech make it the best bang for buck a high percentage of the time, all things considered.
I agree though that the hypertext-browser and application-platform paradigms haven't always been easy to reconcile.
When I say pushed, I don't mean anyone in particular (although big players like Google do it), but rather, pushed by economic (no licenses, no app stores taking chunks) and political forces (availability of professionals, open standards). So, yeah.
Nevermind things that are solved on other application platforms, we now have frameworks that solve things that are solved in the browser. Moving boldly beyond reimplementing page loads with custom Javascript, Youtube now reimplements page load progress bar with custom Javascript.
You sound dismissive of Youtube's page loading. I believe they are loading only those parts of the page that change, which is much faster than re-loading the whole thing. It makes the user experience faster and uses less bandwidth.
What's so insane about it? I would say that the logic for which parts of the page to reload should definitely be in the frontend code, rather than the browser itself.
I do enough front-end to understand why Youtube does what it does. I don't do enough to think that every site implementing its own way to reload parts of pages is a sane idea.
The beautiful thing is that the progress bar in question comes from one of the companies that pioneered lack of a progress bar in the browser. But hey, Javascript.
Google pioneered a minimal browser that left most things up to the sites inside it. Seems to have worked out for them.
If Youtube finds that a progress bar is good for their user experience, more power to them. They can make sure it works as well as possible with their site, and change and remove it if necessary. It seems that you know more about Youtube's design than Youtube's designers.
Next up: have browsers ignore hyperlinks, Youtube designers can come up with a beautiful way to represent and interpret intent to navigate to a different resource and delight users - and change and remove it if necessary
Is there really an application platform that does everything the joint browser-as-application-platform and browser-as-hypertext-viewer can do? Please enlighten me if I'm wrong, but I don't think there is, and I think that's why so many people have been working on improving the experience of the browser-as-application-platform.
So the next funding crunch. Instead of making Snapchat but for dog yoga and building the next great JS framework of the month in the process, developers will have to go back to making boring things that keep working for more than 18 months.
as someone who does very, very little on the side of frontends, i think your time is still invested into a transferable skill that i miss out on:
(frontend) framework design, paradigms and trends. If the stable point you mention will eventually be reached, I am sure everything on the way has contributed and those who have been involved in one way or the other will contribute the most to it and will be the ones that can best contribute to iterative improvements on that stable point.
It must be so wonderful living in your world where there are only a dozen frameworks to choose from. Does money grow on trees there too? Are the streets made of gold? Do people fly their cars to the beach everyday and swim in cherry flavored cola? Please tell us more.
I didn't find the poster's comment offensive. It was a joke; relax and find a sense of humor. Heck; I even up voted the poster to give them some karma since they have a valid point. Sheesh.
My comment was a reflection on your comment—"It must be so wonderful living in your world" implies the parent is shortsighted and was ignoring the difficulties of real-life development.
Rather this was you assuming the worst based on the text, which is a commonly made mistake via text based communications.
I was trying to be humorous since the parent poster had said dozens of frameworks; which I'm sure (s)he is aware is an extremely generous number.
There is a good link here on this common issue as well. Based on the number of down votes my post received; you apparently aren't the only one that took it the wrong way.
Personally; I believe that the way a person interprets something like this speaks more of that person's inherit trust/mistrust of society than anything else. I personally try to take the mindset that most people are on whole decent, nice people if you get to know them.
Exactly; and that number just keeps growing since everyone thinks they can build a better wheel. I agree with the poster; thought what they said was an understatement so I threw out some sarcasm :) Oh noes!
Quick; somebody down vote this guy with his 20 karma! Seriously; down vote me some more people! I want to see what happens after zero!
But we're now in the stage where there's a dozen frameworks out there, probably classifiable into at least three distinct paradigms, and then we have the languages that target the browser. And I suspect we're a long way from shaking this out into a semi-stable point.
The thing that I like least about this treadmill is that time invested in the ephemeral arcana of a stack/platform is time that isn't invested in skills that will transfer elsewhere and help you become a better general problem solver.