Front-end developers could solve all of this by just learning the base technologies of HTML, HTTP, CSS, and JS really well and ignoring everything else.
We're at a beautiful point in web development where browsers are finally unified on open standards, and we're all too locked into these outdated JS frameworks to take advantage of it.
Seeing this mess again tells me that there's something fundamentally wrong with the web or at least with the standardized technologies that are supposed to solve the problem of frontend development (namely HTML, CSS and JS).
I think the web really needs a fresh start before I would even consider becoming a web developer (I'm a CS student atm)
It could simply be that front-end web development is predominantly done by a new, younger generation of programmers, many of whom perhaps didn't come from programming backgrounds but rather a design background.
This generation is only just starting to learn important lessons that the wider programming community learned decades ago about maintainability, portability, the pros and cons of standardisation and of rapid prototyping/evolutionary development, how to design systems of non-trivial scale that can remain useful for extended periods, how to balance the overheads of introducing external dependencies with the benefits of using ready-made, tried-and-tested code and tools, and many other similar issues.
Consequently, that new generation is also only just learning how limited and unfit for modern purposes a lot of the foundations of front-end web development really are. As a direct result, we're now seeing a vast wave of tools, plug-ins, libraries and frameworks designed to paper over the cracks that should never have been there. And because there is little co-ordination or standardisation in the industry, there is also unfortunately a huge amount of wasted work, both for developers of those tools and libraries who are doing the same things repeatedly for no great benefit, and for the potential users who have permanent analysis paralysis.
That much will improve as the industry matures and consolidates, though I fear we are now stuck with HTML/CSS/JS as our foundation, at least until the successor to the Web comes along with things like interactive sites and security-by-default as primary design goals.
Well, OK, but by that argument almost anything is just an upgrade issue, so I'm not sure that really gets us anywhere.
In particular, it doesn't solve the practical problem that even with all the recent developments in the JS ecosystem, as things stand today a lot of front-end web developers don't have access to language features and programming techniques that are widely available in other environments.
Unfortunately, this is just an inherent problem in the way that web tools have been repurposed for more general software development: the developers don't control a significant part of the infrastructure, so they will always have to code to the least common denominator among their target market.
As a front-end developer who came up in the age of defining web standards movement, progressive enhancement and separation of presentation, behavior and styling, reading this makes me feel less relevant than I've ever been.
I haven't kept up with Javascript as I should have, seeing how it developed from a nice little add-on, to being incorporated in AJAX apps like Google Maps and now seeing it eat the industry alive as a full-stack language.
Plain old HTML, CSS and JS seem to be less defined today than ever before considering how much is JS driven and provided through popular frameworks like Bootstrap. It worries me that the entry to relevant web development and web design become more difficult as these approaches advance and what the end user becomes stuck with are one of many platforms and frameworks instead of an ease of creation with the raw code itself.
The problems that technologies like React, Typescript, NPM, etc. solve are mostly only relevant to startups and corporations needing to write business logic and correlate complex projects between teams. The point of front-end frameworks, for instance, is to reduce the roundtrip cost of requests and server-side code by compiling and rendering as much of the site as possible within the browser - an optimization that doesn't matter for most people, but matters when you're "web scale."
Unfortunately, because the web is serious business, all of that complexity became the standard for the entire ecosystem.
Just using HTML/CSS/JS is considered either regressive or niche. It's called "vanilla js" which only shows how utterly locked in to the enterprise paradigm javascript has become, when what should be the default needs its own genre identifier to differentiate it from "the norm."
The issue is exactly this. More and more people are coming into the development space using HTML/CSS/JavaScript and the information on the other technologies is harder to grasp and get a hold of.
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.
Others have mentioned the trend of making everything a SPA, which I agree is a huge part of the problem -- it is a cultural issue, not a technological one. Most apps only need to be HTML with minimal client-side scripting. People who teach front-end need to start out by teaching people how to use static site generators, rather than immediately telling everyone they need to start learning React or Vue.
But I'll also say that the web as an app platform was fundamentally broken from the very start, and this is because it was built on a fundamentally bad programming model. *Why is it* that everyone feels the need to use use virtual-DOM frameworks and CSS preprocessors for all the apps they design? Why is it that whenever I build an app for the web, NPM needs to download and compile around 10,000 modules (no exaggeration) in order to build the app?
JavaScript was originally going to be a Lisp-like language, but OOP was in fashion at the time and so it was made to be more like Java. Had it been a Lisp from the start, at least CSS preprocessors would never have become a thing because with Lisp you have macros. I am not saying the web needs to be based on Lisp, although it would definitely help if things started moving toward web assembly so people can start using better programming languages and frameworks than just the ones that compile to JavaScript to program front-end apps.
The problem is that I think a lot of back-end frameworks change (and/or are created in the first place) as just a means to pad the developer(s) that coined it. All the new implementations of JS that are increasingly more backend just seem like a lazy way of not having to learn a "real" OOP language and just pressing boundaries. Which is great in some respects, but I feel like we could be making better headway as a collective resource by working on improving what's already there (without breaking it in the process) instead of making new things so the new kids to the game don't have to try so hard.
HTML is akin to translating. I know devs who have done front end for 20 years who can't begin to wrap their heads around scripting because it's not just wrapping text in brackets to translate to a screen, but they can pull of tricks in CSS like a shark breathes water. Yes, CSS is a mess and I think a lot of that was trial and error and needs to be standardized, but it's an example still of working to make something that is already there do its job better rather than making something new and shiny to replace it so you can add another language to your portfolio.
This is exactly why I don't do frontend development anymore. The number of tools needed to get an app up and running is ridiculous. Add in cross browser compatibility and it's all just one big headache.
I think modern web misery all stems from an industry problem. Everywhere I've worked, I have insisted on building things with basic semantic HTML, hand coded CSS, and vanilla JS where precisely needed. Nobody listens.
You can make something that loads 50x-100x faster, works responsively on every device, has energy efficient rendering, and the UI/UX is dead simple to use and familiar to all people. And yet... at least for me, I have to fight against every client, employer, and coworker to execute this approach.
Maybe web developers as a whole just got bored. They don't want to make webpages like they did in 2002.
Make a folder with some .HTML, .CSS, .JS files. Then sync it to a linux box. Wow, you're on the internet, a modern marvel. I see younger devs who don't even know this basic stuff. As if, this were all way more complicated than it actually is. It's not.
How do we get web devs back on track? Makers need to thoroughly understand their tools and materials, inside and out, for any industry. I'm just not seeing that as much anymore. It seems like an education problem, or maybe it's just human nature to go for new and shiny instead of practical and reliable.
* The increase in complexity is unavoidable as well as accidental (creep due to marketing). Some of it is necessary to address the increased sophistication of the web. Just compare what we can do today to what we used to do in 1996 with cgi and perl.
* It is not that native GUI libraries like Qt or SDL or GTK are super easy. GUI are event driven and composed and need to be in sync with the user wishes and as such have a programming model that is different from a top to down execution of instructions.
* The biggest challenge with the current state of front end development though is that there are no standards and no stability on a YoY basis. What I learned to do with PHP in 2005 is still valid. I can still use those tricks and whip something useful. What I learned to do with tables in mysql 3.x is still useful with mysql 8.x. However the world of Javascript frameworks is one of shifting sand.
What I learned with Javascript framework X.1 will be obsoleted by X.2 and will be obsoleted by X.3. No guarantees for time investment is challenge #1. angular 1.x -> 2.x, Vue 2.x -> 3.x are some examples that come to mind. Think of all the wasted effort. That is the killer. Humans are good at making peace with whatever crap is thrown at them. I do not think technology is the reason here. It has more to do with hype cycles and trying to catch developer's attention in a competitive market with new buzzwords.
* There is a lack of simple tools like what visual basic used to do. Sure, everything is async and we are in an event driven world but frameworks could have provided a common core to enable simple use cases. bootstrap library is a case in point. I can get decent results with bootstrap without knowing the intricacies of css. However I am hard pressed to find a suitable Javascript framework.
Because front end specialists only think about the front end.
The tide is slowly turning though with Next, SvelteKit, Remix, etc. But still these frameworks are basically just rendering HTML and going full on fat client which is overkill for 80% of interactivity in web app but adds a lot of unnecessary complexity.
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.
- Two of the best developers I know are completely self-taught.
- I'd argue there have been so many front-end frameworks not for the sake of novelty because the web platform itself was incomplete and stagnated. (And also blew a huge opportunity with the APIs for web components.)
- Now that the platform is evolving and innovating again, more and more things are moving out of the frameworks and back into the platform. Javascript has massively improved.
- Some amazing and complex engineering happens in the frontend space because of the constraints and the need to eek performance out of everywhere you can. You can't just throw more servers at the problem.
- Experiences vary, but I've been on more projects delayed by over-engineering the backend than the frontend.
I agree. I recently started learning front end development. My reaction after grasping what modern frameworks do is “my god, what have we done?” It seems like we’ve expended a huge amount of effort to hack the web into something we can build SPAs in (and what an insightful TLA that is).
I wonder if this sort of situation was inevitable or, given sufficient coordination and standardisation, we could have built a better platform. There are some problems that would have to be overcome regardless (eg arbitrary display size[1]) but languages like CSS and JavaScript look like very bad decisions.
My first instinct is that a new platform should be developed based as far as much as possible on tried and tested languages and technologies, but one that also allows for fast-paced browser dev and a path for future evolution.
For now I’m just embracing it and learning. It’s a lot of fun to see how the web works nowadays - I’m already beginning to understand some of the types of bugs that sites exhibit, and why designs are as they are. One of the outcomes has been to develop serious respect for the developers of MS and Google Web apps - eg OneNote on the web - as what they’ve achieved is pretty miraculous when you consider the stack. And those poor web browser devs!
[1] the idea of allowing arbitrary dimensions displays is a very strange one if you consider traditional graphic design; this may be an instance of us geeks making decisions that don’t make sense to more experienced professionals from other backgrounds. How much did graphic designers, UX experts, psychologists etc impact the evolution of the web standards? I don’t know.
What makes it hard is that the "frontend development" space is always rapidly changing.
For instance you can still make sites that are based on static HTML and CSS and that have no Javascript or you can put a few little bits of Javascript in, or you can use a large number of techniques and frameworks to build something that is more like a mobile app than a web page, be it AngularJS or GWT, Enscripten, etc.
First there were the libraries like prototype and JQuery that would smooth over browser incompatibilities, but then the browsers got more compatible. For a long time there was a consensus that a macro language and calculations in CSS would make things worse. Then Blueprint came out and people were excited about that. Then people got sick of all web pages looking the same, and then people realized that the grid was the bad part of Blueprint, it was the other stuff that was good, but then you need a macro languages like LESS, and...
Thus you really have to set some goals for which technologies you want to master, because if you want to master them all you are going to be doing nothing but front-end development for a few years and then you will continuously be scrambling to keep up.
We're at a beautiful point in web development where browsers are finally unified on open standards, and we're all too locked into these outdated JS frameworks to take advantage of it.
reply