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.
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.
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.