6 ms·

Seems very Java-y to me. Like a Everything Inherits From Element kind of philosophy. Historically, one of the core values of browser design is to just provide

Seems very Java-y to me. Like a Everything Inherits From Element kind of philosophy. Historically, one of the core values of browser design is to just provide the minimum possible hooks to access functionality, and to let library authors experiment widely with different APIs and interfaces on top of that. That's why there is so much innovation in things like application lifecycle, layout engines, look-and-feel, etc, on the web. I mean, I get the idea: you can define these custom elements, and then have a bunch of "raw" HTML files that don't use JavaScript and have access to this advanced widgetry. But boy, that's adding a weird layer of confusion. Now those files are "HTML"ish, but can't actually render without this other JavaScript going on. You sacrifice a clear definition of what HTML is. It reminds me of ES6 actually... everyone rushed to add all of this syntactic sugar and comfort features to the language, but now there is no definition of JavaScript anymore. It's just some vague container for some set of possible language properties that may or may not be available on various platforms. I think people underestimate how powerful the web philosophy of "just add the basics, and let people build powerful inferfaces in the application layer" is. We have Rubyists and other folks from pro-oriented languages coming in and trying to turn HTML+JavaScript into a professional programming environment, with all of the chaos and insanity that comes along with that: versioning, build systems, package management, etc. They really don't understand the power of having a single runtime that works everywhere and doesn't do much. Separation of concerns is powerful, and the simplicity of the browser runtime I think provides a helpful constraint which is worth the frustration. The Ember people are near the heart of it. They recently dropped support for Node, making a hard fork where they're only supporting IO.js developers now (franchise naming rights aside). But that attitude is everywhere now. The React crowd is all-in on transpilation. The Webpack people have ditched the idea that there should be some observable relationship between what's in the browser and what's on the filesystem. I don't know. I guess I'm just sad that the JavaScript+HTML community have been taken over by people who don't really seem to like JavaScript+HTML much. And not enough time has passed for those of us who actually like the web to start our equivalent of record stores and classic car clubs. Old man rant over I suppose.

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 ago
  For 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.
madeofpalk 10y ago

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

madeofpalk 10y ago