4 ms·

Here's the older post about riot.js: https://news.ycombinator.com/item?id=6653024 https://news.ycombinator.com/item?id=6653024

niutech 13y ago
Yes, but most of comments under that post are irrelevant since Riot.js no longer depends on jQuery.
- aaronem 13y ago
  Is that why there's a whole section in the linked article talking about jQuery and how great it is and how it works really great with Riot.js? And, sure, you can use something lighter-weight than the full ca. 100Kb jQuery reference implementation, but "1Kb MVP framework", while it sounds awfully nifty, still lacks something in basic honesty by comparison with "1Kb MVP framework, oh, and you have to write a ton of jQuery glue to make anything work with it." [Edit: Don't believe me? Take a look at the Riot.js TodoMVC example[1]. This isn't a framework; this is jQuery with extra hair.] [1] https://github.com/moot/riotjs/blob/master/todomvc/ https://github.com/moot/riotjs/blob/master/todomvc/
  - niutech 13y ago
    There is nothing wrong in using jQuery if you wish, but you can get rid of it as well and just use document.querySelector() and el.addEventListener(). Riot.js is standalone.
    - aaronem 13y ago
      Great, so I can write a bunch of document.querySelector() and el.addEventListener() glue instead. That's a real improvement.
      - tipiirai 13y ago
        I like jQuery. Which library do you prefer for DOM manipulation?
        aaronem 13y ago
        I don't have anything against jQuery per se, but part of the idea behind a client-side framework, or so at least I had gathered in my usual imperfect fashion, was to relieve the developer of the need for a bunch of hand-written DOM-fiddling code, by both attending flawlessly to the common cases and giving the developer flexibility enough to handle the rest as and when it's necessary to do so. That's the point I'm making: I prefer, inasmuch as possible, not to do manual DOM manipulation at all, which renders your question somewhat moot. Perhaps it's different for someone who hasn't written that kind of code enough times to grow thoroughly tired of it, but I have written it that many times, and I am therefore very much open to the suggestion that there's value in a framework which handles the great bulk of such cases automatically, and in so doing gives me more time and effort to spend on whatever project I'm actually working on. Angular, in particular, I've found to be quite good for this; Riot.js, on the other hand, not only doesn't bother with it at all, but takes what I consider to be an unduly snobbish attitude toward the whole concept. For a tiny chat app that's designed to be embedded in third-party pages, I can see some sense in taking the lightweight microframework-style approach. But when its developer and its devotees promulgate it as the prescription for every problem, while denigrating much more capable and general-purpose solutions as "bloated" and casting veiled aspersions upon the competence of the developers who employ them? That's a real problem, and I strongly misdoubt I am the only one to think so. No doubt Riot.js is quite useful in a specific subset of cases, albeit only those closely similar to the one in which it found its origin. But this sort of behavior, on the part of those who already have a stake in it, can only make it less likely that anyone who doesn't have a stake will decide they want one. Certainly it's had that effect on me! -- I was quite interested in Riot.js when it first appeared on HN a few months ago, but that initial interest quickly cooled when I saw how the developer behaves toward his critics. The choice to use any framework, but especially any of the relatively new Javascript ones, implies almost of necessity that the developer so choosing must participate in the community around that framework -- and a community led by someone, who behaves as I've seen the Riot.js developer do, is no community in which I desire to take part. Of course it is that developer's prerogative to behave as he does -- but it is equally the prerogative of anyone else to decide that interacting with someone, who has such an unpleasant attitude toward anyone not unreservedly laudatory of his work, is best avoided. That's precisely the decision I made upon reviewing the original Riot.js thread on HN, and this latest article from the Riot.js developer, in which he arguably outright lies both about the drawbacks of his competition and the benefits of his own entry in the great framework shootout, only reinforces that decision -- and, again, I much misdoubt I'm the only one.

niutech 13y ago

Yes, but most of comments under that post are irrelevant since Riot.js no longer depends on jQuery.

aaronem 13y ago
Is that why there's a whole section in the linked article talking about jQuery and how great it is and how it works really great with Riot.js? And, sure, you can use something lighter-weight than the full ca. 100Kb jQuery reference implementation, but "1Kb MVP framework", while it sounds awfully nifty, still lacks something in basic honesty by comparison with "1Kb MVP framework, oh, and you have to write a ton of jQuery glue to make anything work with it." [Edit: Don't believe me? Take a look at the Riot.js TodoMVC example[1]. This isn't a framework; this is jQuery with extra hair.] [1] https://github.com/moot/riotjs/blob/master/todomvc/ https://github.com/moot/riotjs/blob/master/todomvc/
- niutech 13y ago
  There is nothing wrong in using jQuery if you wish, but you can get rid of it as well and just use document.querySelector() and el.addEventListener(). Riot.js is standalone.
  - aaronem 13y ago
    Great, so I can write a bunch of document.querySelector() and el.addEventListener() glue instead. That's a real improvement.
    - tipiirai 13y ago
      I like jQuery. Which library do you prefer for DOM manipulation?
      - aaronem 13y ago
        I don't have anything against jQuery per se, but part of the idea behind a client-side framework, or so at least I had gathered in my usual imperfect fashion, was to relieve the developer of the need for a bunch of hand-written DOM-fiddling code, by both attending flawlessly to the common cases and giving the developer flexibility enough to handle the rest as and when it's necessary to do so. That's the point I'm making: I prefer, inasmuch as possible, not to do manual DOM manipulation at all, which renders your question somewhat moot. Perhaps it's different for someone who hasn't written that kind of code enough times to grow thoroughly tired of it, but I have written it that many times, and I am therefore very much open to the suggestion that there's value in a framework which handles the great bulk of such cases automatically, and in so doing gives me more time and effort to spend on whatever project I'm actually working on. Angular, in particular, I've found to be quite good for this; Riot.js, on the other hand, not only doesn't bother with it at all, but takes what I consider to be an unduly snobbish attitude toward the whole concept. For a tiny chat app that's designed to be embedded in third-party pages, I can see some sense in taking the lightweight microframework-style approach. But when its developer and its devotees promulgate it as the prescription for every problem, while denigrating much more capable and general-purpose solutions as "bloated" and casting veiled aspersions upon the competence of the developers who employ them? That's a real problem, and I strongly misdoubt I am the only one to think so. No doubt Riot.js is quite useful in a specific subset of cases, albeit only those closely similar to the one in which it found its origin. But this sort of behavior, on the part of those who already have a stake in it, can only make it less likely that anyone who doesn't have a stake will decide they want one. Certainly it's had that effect on me! -- I was quite interested in Riot.js when it first appeared on HN a few months ago, but that initial interest quickly cooled when I saw how the developer behaves toward his critics. The choice to use any framework, but especially any of the relatively new Javascript ones, implies almost of necessity that the developer so choosing must participate in the community around that framework -- and a community led by someone, who behaves as I've seen the Riot.js developer do, is no community in which I desire to take part. Of course it is that developer's prerogative to behave as he does -- but it is equally the prerogative of anyone else to decide that interacting with someone, who has such an unpleasant attitude toward anyone not unreservedly laudatory of his work, is best avoided. That's precisely the decision I made upon reviewing the original Riot.js thread on HN, and this latest article from the Riot.js developer, in which he arguably outright lies both about the drawbacks of his competition and the benefits of his own entry in the great framework shootout, only reinforces that decision -- and, again, I much misdoubt I'm the only one.