3 ms·

I find the whole premise of putting the html in JavaScript bizarre and I think it is a passing fashion while the various debates around web components and shado

by yayana 8y ago

I find the whole premise of putting the html in JavaScript bizarre and I think it is a passing fashion while the various debates around web components and shadow DOM isolation get sorted out. I would hope my graphic artist will eventually be mixing 3 layers of HTML elements that seem entirely standard to him except the 3 different sources of docs.

lsalvatore 8y ago
The only bizarre thing is the HTML was ever separate from JavaScript in the first place.
- yayana 8y ago
  How is that bizarre? Trying to enforce MVC is done even when it is a lost cause.. But you properly separate html, css and (arbitrary Code language to be replaced by transpiling) and all you hear is "I wish my graphic artist had to understand all of this and what a compiler does before he could fix my poor UX ideas.. and my copywriter should have to find my spelling mistakes using an IDE too." If my graphic artist expected me to go into Adobe every time I needed a new background, I would ask him what his job was.
  - lsalvatore 8y ago
    It sounds like you're coming from a landing page/blog/Wordpress background. I'm primarily building data-driven apps, like financial data or dashboards. My UX/UI people don't come near my code, and I wouldn't want them to. For me, every time I need a new button, I'm not going to my designer, I'm just copying over the last button. So I need to be able to quickly edit styles, and state functionality, like dropdowns and date pickers. For these types of components, your life will be a living hell if every time you needed to add a style, you were going to a CSS/HTML file. This was how we first worked with Backbone and Handlebars, and it absolutely sucked.
    - yayana 8y ago
      I see just enough of landingpages and corporate customers and multilingual to see why most of these frameworks ship with toy features when it comes to the lifecycle of the overall site. Then you end up with two parts (a site in so.e kind of CMS and a compiled SPA) that have to look kind of alike where they can only sort of edit one.. Handlebars is just a general text template language so it was naturaly quite rough. From there one can move to dressing components in the angular style and keep the templates all in one folder and the custom CSS in one file. My designer and I share the templates folder, I usually add enough attributes for bootstrap to do something or other and then the custom CSS is his and the code is mine. If we were writing our SPAs for consulting clients it would be essential that the templates and CSS were not compiled so they could go on with them without us and without either paying us to keep a bunch of unstable node tooling able to compile and up to date or feeling like we intentionally snuck a time bomb into the project and are underhanded in seeking hours.
- goatlover 8y ago
  That's probably because HTML came first, and the web was meant to be a document sharing platform, not an app environment for everything under the sun. Anyway, people were mixing the PHP with their HTML long before everything got rewritten in JS. The whole argument over what constitutes proper separation of concerns probably proceeds Smalltalk and MVC.
city41 8y ago
JSX isn't really an abstraction over HTML, it's an abstraction over document.createElement and the other related DOM APIs. I always liked it because that's really what is happening, JS is causing HTML elements to be created via those APIs. We aren't feeding the browser html files for it to parse.
dmitriid 8y ago
> the various debates around web components and shadow DOM isolation get sorted out. They won’t. jQuery was a much simpler concept and basically a fluent wrapper around a lot of existing APIs. 11 years later none of the browser APIs are not nearly as easy to use or powerful as jQuery. (Did you know that querySelectorAll returns an object that, unlike jQuery, isn’t an array and doesn’t have the same APIs? They added frigging .forEach to it only a few years ago). Components are a more complex concept. You need data binding, and virtual DOMs (to prevent out-of-order janky updates to the DOM), and templating, and a solution for both global and isolated CSS, and..., and..., and... These issues won’t be solved in the next 50 years. And that’s the reason no one uses (or talks about) vanilla WebComponents. Everyone is using any of the dozens of wrappers or frameworks on top of them. Edit: added missing not in not nearly as easy

by yayana 8y ago

lsalvatore 8y ago

The only bizarre thing is the HTML was ever separate from JavaScript in the first place.

yayana 8y ago
How is that bizarre? Trying to enforce MVC is done even when it is a lost cause.. But you properly separate html, css and (arbitrary Code language to be replaced by transpiling) and all you hear is "I wish my graphic artist had to understand all of this and what a compiler does before he could fix my poor UX ideas.. and my copywriter should have to find my spelling mistakes using an IDE too." If my graphic artist expected me to go into Adobe every time I needed a new background, I would ask him what his job was.
- lsalvatore 8y ago
  It sounds like you're coming from a landing page/blog/Wordpress background. I'm primarily building data-driven apps, like financial data or dashboards. My UX/UI people don't come near my code, and I wouldn't want them to. For me, every time I need a new button, I'm not going to my designer, I'm just copying over the last button. So I need to be able to quickly edit styles, and state functionality, like dropdowns and date pickers. For these types of components, your life will be a living hell if every time you needed to add a style, you were going to a CSS/HTML file. This was how we first worked with Backbone and Handlebars, and it absolutely sucked.
  - yayana 8y ago
    I see just enough of landingpages and corporate customers and multilingual to see why most of these frameworks ship with toy features when it comes to the lifecycle of the overall site. Then you end up with two parts (a site in so.e kind of CMS and a compiled SPA) that have to look kind of alike where they can only sort of edit one.. Handlebars is just a general text template language so it was naturaly quite rough. From there one can move to dressing components in the angular style and keep the templates all in one folder and the custom CSS in one file. My designer and I share the templates folder, I usually add enough attributes for bootstrap to do something or other and then the custom CSS is his and the code is mine. If we were writing our SPAs for consulting clients it would be essential that the templates and CSS were not compiled so they could go on with them without us and without either paying us to keep a bunch of unstable node tooling able to compile and up to date or feeling like we intentionally snuck a time bomb into the project and are underhanded in seeking hours.
goatlover 8y ago
That's probably because HTML came first, and the web was meant to be a document sharing platform, not an app environment for everything under the sun. Anyway, people were mixing the PHP with their HTML long before everything got rewritten in JS. The whole argument over what constitutes proper separation of concerns probably proceeds Smalltalk and MVC.

city41 8y ago

JSX isn't really an abstraction over HTML, it's an abstraction over document.createElement and the other related DOM APIs. I always liked it because that's really what is happening, JS is causing HTML elements to be created via those APIs. We aren't feeding the browser html files for it to parse.

dmitriid 8y ago

> the various debates around web components and shadow DOM isolation get sorted out. They won’t. jQuery was a much simpler concept and basically a fluent wrapper around a lot of existing APIs. 11 years later none of the browser APIs are not nearly as easy to use or powerful as jQuery. (Did you know that querySelectorAll returns an object that, unlike jQuery, isn’t an array and doesn’t have the same APIs? They added frigging .forEach to it only a few years ago). Components are a more complex concept. You need data binding, and virtual DOMs (to prevent out-of-order janky updates to the DOM), and templating, and a solution for both global and isolated CSS, and..., and..., and... These issues won’t be solved in the next 50 years. And that’s the reason no one uses (or talks about) vanilla WebComponents. Everyone is using any of the dozens of wrappers or frameworks on top of them. Edit: added missing not in not nearly as easy