4 ms·

Having actions tied to the object declaratively is a paradigm that javascript frameworks have been moving towards, rather than away from, for the past few years

by colbyh 12y ago

Having actions tied to the object declaratively is a paradigm that javascript frameworks have been moving towards, rather than away from, for the past few years. When managing a complex, JS-heavy application, it is infinitely more developer friendly to be able to look at an element and figure out what the lifecycle of that object might look like. Instead of digging through javascript (especially jquery heavy code with the possibility of obscured references) where there's no real logic behind when or where an object might be modified, you restrict it to the most basic element possible - the HTML declaration. So yes, let's please reinvent HTML :-)

scotty79 12y ago
> When managing a complex, JS-heavy application, it is infinitely more developer friendly to be able to look at an element and figure out what the lifecycle of that object might look like. Except that what you see in your html is not your element. It's just a forced structure required by w3c (described with xml syntax) for some aspects of visual representation of your element. Your element should be described in js where it can be fairly easily separated out to a single file, and where binding configuration (as well as other concerns such as communication with backend or other app components for example) might be in one place instead of being interspersed with html tags unrelated to that behavior. See how backbone does event binding in views to understand what I'm talking about. > So yes, let's please reinvent HTML HTML is not so much an invention as result of glacial (or w3c-ish in other words) process of semi-(mis)directed evolution. I'm guessing you never had to implement a layout using tables and 1px transparent gifs. I encourage you to try. It might make you understand how rigid and misaligned with the goal HTML in its spirit is. It got some improvements over the years but there was nothing revolutionary in its development even for fairly mild definitions of "revolutionary". Flexbox might become one such mini-revolution when few generations of IE do world a favor and die already. JavaScript is far from being perfect and you can make a horrible mess of it as well, but at least it's general purpose language that supports various mechanisms for abstracting and organizing things and fairly minimalist syntax (as compared to xml, html) for declaring/organizing things that got wide appreciation as JSON.
- colbyh 12y ago
  Javascript, in a browser, exists to manipulate the document. If your opinion is that decoupling the elements of that document from the actions that might happen as a result of interacting with that element then so be it, but I couldn't disagree more. Even if it allows them to live in a "nicer" language (JS vs HTML), I'd rather everything be declared up front. Reading someone else's Backbone code (as compared to Angular or Ember) is really, really not fun for me. YMMV though. Luckily for me, most modern JS frameworks are similarly opinionated.
  - scotty79 12y ago
    > I'd rather everything be declared up front. I'm all for declaring up front, just not in html. > Reading someone else's Backbone code (as compared to Angular or Ember) is really, really not fun for me. Backbone is far from what I consider good readability. If encourages bad habits by not providing templating and sort of encouraging use of jQuery for dom modification. Binding events to backbone view is what I consider good readability.
    - colbyh 12y ago
      Finally, we can both agree that jquery dom manipulation is a great way to find yourself in a mess of unmaintainable code. If you're a fan of backbone views though - why not React? IMO it's very similar to backbone but with sane structure and an incredibly powerful render loop.
      - scotty79 12y ago
        I haven't paid much attention to React before reading this http://jlongster.com/Removing-User-Interface-Complexity,-or-Why-React-is-Awesome http://jlongster.com/Removing-User-Interface-Complexity,-or-... Now I think the idea is awesome and architecture that arises from it might be very good. But this idea assumes that DOM manipulation is fast enough to do every render frame and I do not trust yet the caching magic that React.js conjures to ameliorate the fact that it actually isn't.

by colbyh 12y ago

scotty79 12y ago

> When managing a complex, JS-heavy application, it is infinitely more developer friendly to be able to look at an element and figure out what the lifecycle of that object might look like. Except that what you see in your html is not your element. It's just a forced structure required by w3c (described with xml syntax) for some aspects of visual representation of your element. Your element should be described in js where it can be fairly easily separated out to a single file, and where binding configuration (as well as other concerns such as communication with backend or other app components for example) might be in one place instead of being interspersed with html tags unrelated to that behavior. See how backbone does event binding in views to understand what I'm talking about. > So yes, let's please reinvent HTML HTML is not so much an invention as result of glacial (or w3c-ish in other words) process of semi-(mis)directed evolution. I'm guessing you never had to implement a layout using tables and 1px transparent gifs. I encourage you to try. It might make you understand how rigid and misaligned with the goal HTML in its spirit is. It got some improvements over the years but there was nothing revolutionary in its development even for fairly mild definitions of "revolutionary". Flexbox might become one such mini-revolution when few generations of IE do world a favor and die already. JavaScript is far from being perfect and you can make a horrible mess of it as well, but at least it's general purpose language that supports various mechanisms for abstracting and organizing things and fairly minimalist syntax (as compared to xml, html) for declaring/organizing things that got wide appreciation as JSON.

colbyh 12y ago
Javascript, in a browser, exists to manipulate the document. If your opinion is that decoupling the elements of that document from the actions that might happen as a result of interacting with that element then so be it, but I couldn't disagree more. Even if it allows them to live in a "nicer" language (JS vs HTML), I'd rather everything be declared up front. Reading someone else's Backbone code (as compared to Angular or Ember) is really, really not fun for me. YMMV though. Luckily for me, most modern JS frameworks are similarly opinionated.
- scotty79 12y ago
  > I'd rather everything be declared up front. I'm all for declaring up front, just not in html. > Reading someone else's Backbone code (as compared to Angular or Ember) is really, really not fun for me. Backbone is far from what I consider good readability. If encourages bad habits by not providing templating and sort of encouraging use of jQuery for dom modification. Binding events to backbone view is what I consider good readability.
  - colbyh 12y ago
    Finally, we can both agree that jquery dom manipulation is a great way to find yourself in a mess of unmaintainable code. If you're a fan of backbone views though - why not React? IMO it's very similar to backbone but with sane structure and an incredibly powerful render loop.
    - scotty79 12y ago
      I haven't paid much attention to React before reading this http://jlongster.com/Removing-User-Interface-Complexity,-or-Why-React-is-Awesome http://jlongster.com/Removing-User-Interface-Complexity,-or-... Now I think the idea is awesome and architecture that arises from it might be very good. But this idea assumes that DOM manipulation is fast enough to do every render frame and I do not trust yet the caching magic that React.js conjures to ameliorate the fact that it actually isn't.