Some articles recently have had an impact on me, and they are important for context in this debate that is boiling up in our industry. I recommend reading The Great Divide, HTML CSS and Our Vanishing Entry-Points, by Rachel Andrews - as well as HTML is a Compilation Target by Christian Heilmann.
I don't actually feel all that angry about the way CSS and HTML are being treated. I feel worried. And, as is normal, the worry is about identity and how I'm perceived by others. I'm worried that I am being foolish and short-sighted about web app development. And I'm worried that I'm not actually the kind of web designer that I thought I was.
And what is that identity I'm worried about maintaining? I started as the guy who does HTML and CSS cutup of photoshop files. I worked at a small agency with one other designer and several "programmers". We built hundreds of websites for small businesses. I had been making websites for myself and other since 1999, but when I graduated from college and started a "career" I really grew into an expert with CSS and all the little browser quirks and tricks that needed to be discovered the hard way.
I convinced the other people in my team to move from table layouts to pure CSS around 2006. Floats, man. Floats... Shudder
I had taken computer science classes in college along side all the design and communication classes, but it wasn't really something I loved. I thought of myself as a designer first, but I was expected to turn my photoshop designs into real flexible web page templates that could handle any content that a CMS might put into them. And doing that design work in a browser was a lot of fun for me. The mysterious alchemy of server side programming was still a little bit beyond what I was comfortable with, despite a few forays into PHP during college. Eventually, I began scripting interactions inside Flash widgets and "Rich Internet Applications". I was able to take that knowledge and begin applying that to javascript in the browser. And around that time jQuery came out and made everything so much better.
Due to some weird career shifts I found myself as a developer on an enterprise backend web development team in 2010. I found myself learning new skills rapidly, backend programming with C# and ASP.Net MVC, database design, architecture diagrams, big enterprise software development lifecycle procedures.
What I've discovered over the past 20 years is that really what I wanted all along was to build awesome experiences that were easy to build and easy to share. HTML and CSS were never "the easy entry point", they were the weird technical fiddly syntax that you needed to learn to manipulate to get the desired output on the screen. Learning to be a programmer was something that had to happen organically as I needed it. Now that I've been diving deep into coding javascript applications for the last 5 years, and writing backend server apps for 9 years, I can say that I don't care to treat HTML and CSS as anything particularly "precious". They are just the structured data formats that are needed to tell the browser how to render the UI. If we have layers of tools that can create all the necessary HTML and CSS dynamically from javascript, then it doesn't really matter to me. We can still make that app accessible, we can still make it performant, we can still open it up in developer tools and view all the DOM nodes and style properties.
I don't think writing all your CSS in JS is a good idea. I think we can still build useful and reusable CSS that takes advantage of the cascade, instead of fearing it. We can deal with the nature of global scope through understanding instead of just overwriting everything with a random ID to create isolation. CSS was built as it is for a reason, it's worthwhile to know the why's and understand how to use those aspects. But, that doesn't mean it's always wrong to subvert the usual expectations of how CSS works. Atomic CSS is a great example of this.
I've always held onto an identity as a frontend developer, even while I was focusing on design, or server-side development. And now that my own vision of frontend developer fits more closely with the larger view of the flood of newer JS engineers that build single page apps and bypass HTML and CSS when it's convenient, I wonder if I'm being short-sighted and irresponsible with my craft. I care about treating the web responsibly with a long-term perspective on our work being usable for dozens of years. If we build a content website with a JS toolchain we need to make sure it's outputting static HTML pages that are enhanced by JS when it's loaded - like Nuxt does.
I ended up in a place where I think the modern toolchains and SPA development frameworks are really exiting and useful. I know more than I ever expected to know about the event loop, the call stack, virtual-dom, and functional code. And it was my choice to pursue learning what I did. I have privilege and luck and a great deal of enthusiasm to help me arrive at the side of the divide where I am. I can tell you it's not a great divide anymore, It's just exciting to look out across a rich and varied landscape of web development approaches and think back fondly on the peaks that I've stood upon in the past and look ahead to the foggy future where more exiting climbs await me.
Top comments (5)
You've forgotten a lot from your design entry point if that's all you think HTML and CSS are and that they're no different in their affordences than any other way of telling a browser how render something on the screen. Remember how design takes into account the human beings it's intended for, their context, and their psychology? Remember how you used to not know how to program and found it intimidating? Yet clearly somehow found HTML and CSS approachable in a way PHP wasn't? There were WYSIWYGs and programmatic APIs for building UIs back then, too. Why didn't you use them instead of writing HTML and CSS? What's actually different about JavaScript and today's tools compared to the options 20 years ago? And as a real programmer now, you actually think data hydration has good performance compared to actual static server side delivered static HTML as a rule? And that there's no difference between how HTML and CSS are interpreted in the client compared to a scripting language? They're equivalent choices and it's fine to replace them with each other because the substitution has no negative consequences whatsoever?
Can you please tell me what context and psychology I'm overlooking?
As I understand it, HTML and CSS load directions into a rendering engine for "presenting" things to the user. My mental model of users is that they want to do jobs by interacting with the interface presented to them. JS can do this too, when it builds DOM nodes. Of course, it does it a little slower because of downloads needing to be complete before parsing can happen, and the parsing and execution of scripting logic is bound to be slower than the parsing of declarative markup. But, I believe there are many, many, scenarios where that difference would be imperceptible to the user.
I did use those UIs like Frontpage and Dreamweaver and Word. They generated code for me that I could then tear apart and understand, eventually. I haven't heard anyone suggesting that browsers stop supporting HTML and CSS as first-class methods of encoding content and rendering instructions. I believe those things will still work and continue to be an important entrypoint for document publication and content authoring. I would still start every new developer on the path by introducing them to HTML and CSS first. But the types of problems those coders can solve will expand greatly when they start using more advanced tools.
I think my point is that you should try to see things from a perspective you no longer have. I could list a bunch of things, but you wouldn't agree unless you thought of them yourself.
Because those coders should not need to solve those problems. It's clear that you're no longer a designer. You are a programmer. But not everyone in the world should be a programmer. That's the behind the design of those languages. They're inclusive for non-programmers.
And people are absolutely suggesting browsers prioritize programmers and JS as first class over non-programmers and HTML and CSS. Every single day someone suggests getting rid of HTML and CSS on Twitter. People as high profile as Kyle Simpson suggest HTML will go away over the next few years. People as high profile as Dan Abramov suggest WYSIWYGs which only allow designers to use already-created components are exactly what designers need.
Remember the browser wars and realize we're in framework and WYSIWYGs wars today. But few are speaking up for standards or languages that invite the participation of non-programmers. Many are circumventing the web platform's inclusive, resilient, better performing foundations as much because it pleases their egos as because it solves a problem. And many more are simply following along without the least thought to the impact.
How would the web platform's inclusiveness survive this intact if few are caring for it?
That's a good point, I no longer have the perspective that got me into this whole web development thing. I listen to a lot of podcasts which feature developers who have started in the last few years though, so I try to stay as in-touch as I can.
You are right, HTML and CSS are easier to teach and learn than JS. I agree that people who would hasten the demise of those technologies should be questioned about the inclusivity of their replacements.
I still don't see the harm in building apps and experiences for my customers and users that circumvent HTML and CSS authoring. I'm not creating it for the users to examine on that level. If they need to learn how to do something there will be other resources and examples of how to create parts of what I've created in my interface.
WYSIWYG development tools have always been an option that helps some people get into programming and which eventually impede and annoy those who have mastered the underlying technologies. I wanted a good WYSIWYG tool when I was starting, I loved flash for that reason. But every WYSIWYG tool I've worked with has had a "hood" you can "pop" to see what's going on, and override the instructions the tool thought you intended - I doubt future iterations will abandon that and make everything be perfectly shrink-wrapped at the browser level.
I don't think they're all bad either. And I hope that popping the hood does stick around! In fact, I hope that interaction evolves and proliferates--it's not really that far from what view source used to accomplish for beginners and what dev tool inspectors do better now with their ability to live edit. Just targeted toward creation of certain things. I kinda wish a browser vendor would take a real go at those use cases as built in dev tools. Make the browser truly both an IDE and design tool.
I'm being only as alarmist about it as I have direct reason to be, though. Coincidentally, a few weeks ago I was chatting with a developer working on a design tool project like I mentioned. I and another dev who identified himself as a designer who codes agreed much like you and I have that there's inherent value in a WYSIWYGs, but that all designers don't need to be isolated from code, that there is a virtuous cycle sort of effect in synergy between code and a GUI, and that we thought there was a lot of room for useful innovation in exploring it and bringing more people into contact with code when they have the interest. Which more people naturally will when they find it a rewarding experience because it helps them do things they want (like design) and aren't scoffed at as innately unsuited to do it. The developer involved in building this new tool argued with us for days that in no way should designers touch code. He even argued that designers weren't qualified to design new UI patterns without a front end developer like him holding their hands.
I suppose he's entitled to his opinion, but I think he's very wrong. And it's not the first time I've heard it, not even close. Like you, I've wandered from my design entry point. But due to how I've specialized I've stayed in close contact and being primarily a coder while still not an insider has given me the opportunity to catch a lot of flak.