5 ms·

I feel like this is one of those cases where someone rejects currently existing tools, but then goes on to throw out the baby with the bath water when trying to

by lhorie 11y ago

I feel like this is one of those cases where someone rejects currently existing tools, but then goes on to throw out the baby with the bath water when trying to come up with an alternative. Figure 7 (http://cdn.infoq.com/statics_s2_20160209-0057/resource/articles/no-more-mvc-frameworks/en/resources/fig7.jpg http://cdn.infoq.com/statics_s2_20160209-0057/resource/artic...) looks to me like the sort of MVC you would do with vanilla PHP or friends back in the day. In figure 9 (http://cdn.infoq.com/statics_s2_20160209-0057/resource/articles/no-more-mvc-frameworks/en/resources/fig9.jpg http://cdn.infoq.com/statics_s2_20160209-0057/resource/artic...): he handwaves saying that you can compose things, but nothing in the article suggests that SAM provides better mechanisms to sync data between client and server. E.g. what if the view is a table, and the action is deleting an item? Does an update consist of re-downloading a whole new table worth of data? Would it also do that if I deleted that same item from some other view? Or does it require 2 http requests in series (a DELETE followed by a GET)? What would an undo action look like in terms of HTTP requests and responses? The graphs feel like they're largely meaningless. Having arrows in a diagram pointing from one word to another doesn't say anything about the complexities of the system.

carsongross 11y ago
> I feel like this is one of those cases where someone rejects currently existing tools, but then goes on to throw out the baby w/ the bath water when trying to come up w/ an alternative. Humorously, this is exactly what the current set of client side MVC libraries did.
- lhorie 11y ago
  No offense, but I think it's disingenous to compare the SPA movement with a guy with vague graphs that look like they suggest going back to what people used to do 5-10 years ago. The SPA movement "threw out" the notion of ajaxing HTML snippets in favor of ajaxing structured data for many reasons: better separation of concerns, better asset cacheability, better defaults against XSS, better infrastructure for multi-client architectures, the list goes on. I'd argue that security w/ data endpoints is far easier to audit and reason about than the old school RPC-style send-me-html-when-I-do-X server interfaces.
  - EGreg 11y ago
    AJAXing data is great (It should be AJAJ btw :) But when do you update the view? Angular dirty-checks the model on each $digest cycle. React dirty-checks the view. Why not simply require the component to call a function to indicate it's changed a couple variables in its state? Simply keep references to the DOM elements in your component and update them. It's much faster and gives you more control, and a programmer who forgets to write the function call will realize it as soon as they don't see the update. The IDE or linter can even have a static analyzer that flags a missing call to the function. I think that a lot of times these attempts at convenience (such as Angular's two way binding, or the virtual DOM) just throw more layers of complexity and slow things down from a relatively simple straightforward approach, while providing little other than saving keystrokes.
    - lhorie 11y ago
      > Why not simply require the component to call a function to indicate it's changed a couple variables in its state This is actually roughly what knockout and ember (pre-glimmer) do. They are known as KVO (key-value observer) systems and have implementation challenges of their own: knowing when to batch operations, dealing w/ computed properties and rx glitches (in reactive systems, a "glitch" is the name given to temporary inconsistencies that occur between stable states), and added complexity in terms of requiring the model layer to be observable-based (as opposed to POJOs in Angular/React/friends). Also, high quality KVO systems are far more difficult to implement. To my knowledge, Vue is currently the fastest KVO-based javascript library in existence and in order to support its POJO-like model API, it's significantly larger than Snabbdom (which is one of the fastest vdom implementations currently, despite clocking at a mere 200-300 LOC) AFAIK, most of the challenges faced by KVO system have not been as extensively explored (at least by the javascript community) as virtual dom algorithm optimizations have, so currently I believe high quality virtual dom libraries are likely to perform better at various real life scenarios than current state-of-art KVO systems.
      - EGreg 11y ago
        Right. But why not just make the app developer explicitly specify that some variables in the state have changed, and let the developer and requestAnmationFrame do the batching? After all, they are the best positioned to know when a batched update has been done.
Symbiote 11y ago
> baby w/ the bath water when trying to come up w/ an … w/ Would you mind writing "with"? It's two extra characters, but it makes the sentence much more readable. (Words are recognized by shape, especially the shortest ones.)
- david-given 11y ago
  OP has since reedited their comment --- thank you very much for that, OP!
- orf 11y ago
  > Words are recognized by shape, Words are recognized by shape w/ is both incredibly short and has a very unique shape.
  - kuschku 11y ago
    Many people – including people speaking english as second language – are unfamiliar with it. I, for example, didn’t know w/ meant with until now.
    - leeleelee 11y ago
      It's pretty common. Now that you know what it means, you'll grow to like it.
    - mrexroad 11y ago
      And to think, there's an alternate 'verse where the above comment was s/w\//with/, you'd still not know...
    - deleted 11y ago
      [deleted]
- savanaly 11y ago
  It's easier for me to parse "w/", for the record. You're right that words recognizeable by shape, and "w/" looks really distinct to me.
leeoniya 11y ago
Hey Leo, I must say, I've also become disillusioned with MVC for front-end frameworks, actually after using Mithril [1]. I'm sure you've seen me lurking and asking questions in the repo since before Mithril got big. I used it on a few projects and decided the controller was not an abstraction that made much sense. I looked elsewhere and stumbled upon domchanger [2] but after trying to use it seriously and forking some changes also ran into many impasses. This is what inspired me to develop domvm [3], a simple, pure-js composable vdom view layer for plain models. I took a few of Mithril's good ideas, removed globals, made the magic as opt-in modules (so a bit more wiring is needed) and ended up with something extremely fast (at least 2.5x Mithril), composable and mixed imperative/declarative. It's been a good journey and I'm very happy where everything ended up. Thanks for some inspiration :) [1] http://mithril.js.org/ http://mithril.js.org/ [2] https://github.com/creationix/domchanger https://github.com/creationix/domchanger [3] https://github.com/leeoniya/domvm https://github.com/leeoniya/domvm
- lhorie 11y ago
  Hi leeoniya. domvm is a an interesting project that I've been keeping my eyes on. I'm thinking of adapting some of your ideas for the rewrite of Mithril that I'm working on, particularly APIs related to re-rendering control. Stay tuned :)
  - rattray 11y ago
    Wow, what a gracious reply. Best of luck to you both!
    - leeoniya 11y ago
      Indeed, i have no intention of marginalizing the excellent engineering that Leo has put into Mithril, it is a solid lib and if it "clicks" for you then by all means use it. I would be delighted if my projects had a positive effect on a Mithril rewrite. I originally wanted to improve Mithril but alas it was not architecturally possible without large BC breakage and alienating the existing userbase. Actually, as a proof of concept I wrote an adapter for domvm that allows Mithril's link rotator demo to work unmodified: https://github.com/leeoniya/domvm/tree/master/demos/mithril-adapter https://github.com/leeoniya/domvm/tree/master/demos/mithril-... In the end everything in software is an iteration of something else.
dk8996 11y ago
I agree with you. One point I'd like to make, there is a big difference between white papers and real applications running production. Architectures are just general guidelines and won't perfectly fit every real world problem. Moreover, part of why Software Eng. are in high demand and well payed is because we have to deal with complexities that real world problems bring with them.

by lhorie 11y ago

carsongross 11y ago

> I feel like this is one of those cases where someone rejects currently existing tools, but then goes on to throw out the baby w/ the bath water when trying to come up w/ an alternative. Humorously, this is exactly what the current set of client side MVC libraries did.

lhorie 11y ago
No offense, but I think it's disingenous to compare the SPA movement with a guy with vague graphs that look like they suggest going back to what people used to do 5-10 years ago. The SPA movement "threw out" the notion of ajaxing HTML snippets in favor of ajaxing structured data for many reasons: better separation of concerns, better asset cacheability, better defaults against XSS, better infrastructure for multi-client architectures, the list goes on. I'd argue that security w/ data endpoints is far easier to audit and reason about than the old school RPC-style send-me-html-when-I-do-X server interfaces.
- EGreg 11y ago
  AJAXing data is great (It should be AJAJ btw :) But when do you update the view? Angular dirty-checks the model on each $digest cycle. React dirty-checks the view. Why not simply require the component to call a function to indicate it's changed a couple variables in its state? Simply keep references to the DOM elements in your component and update them. It's much faster and gives you more control, and a programmer who forgets to write the function call will realize it as soon as they don't see the update. The IDE or linter can even have a static analyzer that flags a missing call to the function. I think that a lot of times these attempts at convenience (such as Angular's two way binding, or the virtual DOM) just throw more layers of complexity and slow things down from a relatively simple straightforward approach, while providing little other than saving keystrokes.
  - lhorie 11y ago
    > Why not simply require the component to call a function to indicate it's changed a couple variables in its state This is actually roughly what knockout and ember (pre-glimmer) do. They are known as KVO (key-value observer) systems and have implementation challenges of their own: knowing when to batch operations, dealing w/ computed properties and rx glitches (in reactive systems, a "glitch" is the name given to temporary inconsistencies that occur between stable states), and added complexity in terms of requiring the model layer to be observable-based (as opposed to POJOs in Angular/React/friends). Also, high quality KVO systems are far more difficult to implement. To my knowledge, Vue is currently the fastest KVO-based javascript library in existence and in order to support its POJO-like model API, it's significantly larger than Snabbdom (which is one of the fastest vdom implementations currently, despite clocking at a mere 200-300 LOC) AFAIK, most of the challenges faced by KVO system have not been as extensively explored (at least by the javascript community) as virtual dom algorithm optimizations have, so currently I believe high quality virtual dom libraries are likely to perform better at various real life scenarios than current state-of-art KVO systems.
    - EGreg 11y ago
      Right. But why not just make the app developer explicitly specify that some variables in the state have changed, and let the developer and requestAnmationFrame do the batching? After all, they are the best positioned to know when a batched update has been done.

Symbiote 11y ago

> baby w/ the bath water when trying to come up w/ an … w/ Would you mind writing "with"? It's two extra characters, but it makes the sentence much more readable. (Words are recognized by shape, especially the shortest ones.)

david-given 11y ago
OP has since reedited their comment --- thank you very much for that, OP!
orf 11y ago
> Words are recognized by shape, Words are recognized by shape w/ is both incredibly short and has a very unique shape.
- kuschku 11y ago
  Many people – including people speaking english as second language – are unfamiliar with it. I, for example, didn’t know w/ meant with until now.
  - leeleelee 11y ago
    It's pretty common. Now that you know what it means, you'll grow to like it.
  - mrexroad 11y ago
    And to think, there's an alternate 'verse where the above comment was s/w\//with/, you'd still not know...
  - deleted 11y ago
    [deleted]
savanaly 11y ago
It's easier for me to parse "w/", for the record. You're right that words recognizeable by shape, and "w/" looks really distinct to me.

leeoniya 11y ago

Hey Leo, I must say, I've also become disillusioned with MVC for front-end frameworks, actually after using Mithril [1]. I'm sure you've seen me lurking and asking questions in the repo since before Mithril got big. I used it on a few projects and decided the controller was not an abstraction that made much sense. I looked elsewhere and stumbled upon domchanger [2] but after trying to use it seriously and forking some changes also ran into many impasses. This is what inspired me to develop domvm [3], a simple, pure-js composable vdom view layer for plain models. I took a few of Mithril's good ideas, removed globals, made the magic as opt-in modules (so a bit more wiring is needed) and ended up with something extremely fast (at least 2.5x Mithril), composable and mixed imperative/declarative. It's been a good journey and I'm very happy where everything ended up. Thanks for some inspiration :) [1] http://mithril.js.org/ http://mithril.js.org/ [2] https://github.com/creationix/domchanger https://github.com/creationix/domchanger [3] https://github.com/leeoniya/domvm https://github.com/leeoniya/domvm

lhorie 11y ago
Hi leeoniya. domvm is a an interesting project that I've been keeping my eyes on. I'm thinking of adapting some of your ideas for the rewrite of Mithril that I'm working on, particularly APIs related to re-rendering control. Stay tuned :)
- rattray 11y ago
  Wow, what a gracious reply. Best of luck to you both!
  - leeoniya 11y ago
    Indeed, i have no intention of marginalizing the excellent engineering that Leo has put into Mithril, it is a solid lib and if it "clicks" for you then by all means use it. I would be delighted if my projects had a positive effect on a Mithril rewrite. I originally wanted to improve Mithril but alas it was not architecturally possible without large BC breakage and alienating the existing userbase. Actually, as a proof of concept I wrote an adapter for domvm that allows Mithril's link rotator demo to work unmodified: https://github.com/leeoniya/domvm/tree/master/demos/mithril-adapter https://github.com/leeoniya/domvm/tree/master/demos/mithril-... In the end everything in software is an iteration of something else.

dk8996 11y ago

I agree with you. One point I'd like to make, there is a big difference between white papers and real applications running production. Architectures are just general guidelines and won't perfectly fit every real world problem. Moreover, part of why Software Eng. are in high demand and well payed is because we have to deal with complexities that real world problems bring with them.