4 ms·
The logical extreme of your argument is to make everything a `div` with classes. While possible, the main issue with that model is that it provides no encapsul
by rtpg 10y ago
The logical extreme of your argument is to make everything a `div` with classes.
While possible, the main issue with that model is that it provides no encapsulation strategy. Encapsulation is one of the core tools for programmers for building complex programs, so having first class support for that in the templating language suddenly makes a lot of things easier.
Without encapsulation, a lot of things become more frustrating. Event bubbling has to be micro-managed. Dev tools are less useful. It becomes even more frustrating to deal with conflicting CSS IDs.
Steele's Growing A Language[0] talk specifically points to encapsulation as the core building blog for programs. Given how HTML is used nowadays (React + Angular are both "HTML as program layouts" models), not having encapsulation is a crutch
[0]: https://www.youtube.com/watch?v=_ahvzDzKdB0 https://www.youtube.com/watch?v=_ahvzDzKdB0
- erikpukinskis 10y agoFor me the logical extreme is "use the most basic control structures you can get away with". And it's easy (and useful) to use `a` tags and `span` tags and even `p` and `h1` tags every now and then. Also, `canvas` is quite useful, and `input` not to mention `script`, `link`, ... Actually, now that I think about it, there are lots of tags I use that aren't `div`. Writing the shims to reimplement all of those is exactly counter to what I am suggesting. I am saying, use what's there unless you have a really really good reason. > Without encapsulation, a lot of things become more frustrating. I'm not talking about encapsulated vs. raw, I'm talking about two things mostly: 1) declarative vs imperative. 2) bundled frameworks vs single purpose tools Angular is a huge monolith that one must boot and then understand, because the way it does work for you is by having you declare things correctly on the filesystem and in magical scopes. Jquery is bundled, but it's imperative. Webpack is declarative, but it's not bundled. I have no problem with tooling I just think the way we are designing tools is going entirely in the wrong direction. The general question to ask is: how many systems do I need to understand in order to be able to describe what this tool I am using will do? If the tool is Rails, the answer is "there is no end to the number of systems you need to understand in order to be able to describe what this Rails app will do". If the tool is a PHP binary, the answer is much narrower.