I'd like to make a point for the separation of concerns in web development.
HTML is a language that's been created for structuring and linking doc...
For further actions, you may consider blocking this person and/or reporting abuse
Thank you for the article! In a time when React and the like are accepted so readily, this is a refreshing change of perspective.
I think the big problem is that there is a tension between separation of concerns, as you defined it, and componentization. Using HTML, CSS and JavaScript as they were originally meant to is nice, but so is having reusable components.
That, and the other issues you raised, is the reason I like Svelte so much. First, it lets you write actual HTML and actual CSS at the same time as having components, with all the perks this brings. It is the best of both worlds. And, since it compiles itself away, you are shipping just the JavaScript you actually need. The end result the user receives is basically what you would've written in vanilla JS, except you get there much more easily.
I don't have any experience with Svelte, but everyone I spoke to about it was amazed. Definitely have to give it a look.
Nonetheless I'd argue that you still have to carefully evaluate what "only the js you actually need" is. That holds true even for vanilla.
Sadly the development industry is mostly driven by fads.
There are many technologies. The old ones worked well, but have lost favor, so now there's new ones. Its also big business to get people to use your stuff.. So things change, even when they don't need to.
But there is real risk going against the fads and using things that are not yet (or ever) in style, or have lost favor:
All these factors may lead to a re-write, which can often be a death sentence for the project.
I've seen many great technologies come and go.. because developers decided to go with something else that excited them. Even when the new thing is much less capable and much less tested.
Nice, if we don't have to target 98% of browsers, as
Don't know how I missed this four years ago, but better late than never.
This is an excellent article.
It's not really about "separation of concerns". We can choose whatever "concerns" we want and split the code in different ways. Whether that makes sense or not depends on the circumstance. The arguments around SoC are like arguing how many angels can dance on the head of a pin. Who cares?
What is important is performance. The ability of the devs to understand the code and write it quickly with few or no bugs and little tech debt. The ability of the user to understand the interface quickly and get things done. The ability of the company to make the product profitable.
And the key to all three of these — assuming that you're making the right product for the right people with the right features — is cognitive footprint.
Cognitive footprint is simply the cognitive load over the lifetime of the product. The code has a cognitive footprint. The interface has one, too.
The argument for separating the HTML, CSS, and JS is that doing so greatly reduces cognitive load. If we work with a component architecture and we keep components small and simple (but composable), then we're never dealing with more than a few lines of code at a time.
Throw in good naming and a few design principles (such as grouping like things, proper use of whitespace including indentation, etc.), and the code becomes as easy to read as a nursery rhyme.
You can put all your code — HTML, CSS, and JS — in a single file if that works for you. But using a programming language to generate all your HTML and CSS just makes it very difficult to grok what's happening. This, BTW, is the great feature of JSX: it looks like the HTML it produces.
I don't believe that this argument is a matter of opinion or preference. Cognitive load is measurable. We should be able to measure which approach results in the least load, hence effort.
My money is on keeping HTML, CSS, and JS/TS separate.
I talk about this quite a bit on the Craft Code site.
Meanwhile the boundaries between websites and web apps is getting blurry, and application frameworks start to target smaller and smaller units of functionality.
Which is a good thing. I'm not even complaining about heavy framework usage in itself. I'm about how the heaviest frameworks are used in even the smallest projects.