4 ms·

And here is Tom Dale's reply: http://tomdale.net/2015/11/javascript-frameworks-and-mobile-performance/ http://tomdale.net/2015/11/javascript-frameworks-and-mobi

And here is Tom Dale's reply: http://tomdale.net/2015/11/javascript-frameworks-and-mobile-performance/ http://tomdale.net/2015/11/javascript-frameworks-and-mobile-...

yomism 11y ago
Guy that makes a framework replying that frameworks are good. Aha....
- timrpeterson 11y ago
  I see what you are doing but, that's not relevant to his point.
- pkozlowski_os 11y ago
  Well, I believe it is a "good thing" when you believe in what you do and got arguments to back up what you believe in.
  - btrask 11y ago
    Advocate something you do: cynical self-interest Advocate something you don't do: hypocrite
- talles 11y ago
  Guy that makes a framework thinks that frameworks are good. Perfect sense to me.
wwweston 11y ago
> frameworks let you manage the complexity of your application Close. Front-end frameworks are one solution to the problem of managing the complexity involved in making an app. After working with a few of them, I'm not really sure that they're the best ones.
- kornish 11y ago
  Could you elaborate on what some other solutions are?
  - matthewtoast 11y ago
    I'm not the parent commenter but here are a few that come to my mind: - Functions - Abstraction - Modularity - Design patterns - Programming paradigms - DSLs - Conventions for naming/formatting/arrangement Although I grant that any of these could possibly work even better when codified into a framework.
    - collyw 11y ago
      Frameworks will be implemeting a number of these for you.
  - solidr53 11y ago
    Microservices
lhorie 11y ago
(Disclaimer: I'm the author of Mithril.js) Is it my impression or is Paul on some sort of a crusade to downplay the dev ergonomics of React and try to convince people that it's "slow"? TodoMVC benchmarks have been done before: https://github.com/pygy/todomvc-perf-comparison https://github.com/pygy/todomvc-perf-comparison . So sure, there's room for performance improvements in mainstream frameworks, and React is not the fastest thing in the universe, but come on. Maintaining a large project in vanilla js is largely equivalent to writing code in assembler when there are good C compilers: it's doable, and required in a handful of situations, but not really wise for 99% of real world projects. Re: Tom's response: Something that he didn't mention (which is not surprising since he's an Ember dev) is that frameworks do sometimes detract from end user experience by imposing "opinionated" complexity and assumptions that might prevent devs from doing certain specific things and settling with suboptimal UX - the old adage of "if you want to deviate from the holy way(tm) you're on your own" I'm kinda in the middle of the two opinions: it's definitely important to have access to the "metal" (both in terms of actually being able to code against low level APIs, and in terms of the amount of effort required to wade through framework abstractions in order to get there), but even using vanilla js, a complex app does need a "framework" (in the sense of having rules for where things should be and how they should interact with one another, and in the sense that any non-trivial app will have "library-level" plumbing). So, why not meet in the middle and use a lightweight framework that does 95% of things well enough to actually be used in non-trivial mobile apps[1] but that doesn't have high enough byte count to be bloated? [1] http://en.lichess.org/mobile http://en.lichess.org/mobile
untothebreach 11y ago
Seems to have gotten the HN hug-o-death, so here is the cached version: http://webcache.googleusercontent.com/search?q=cache:cPuIbivGESIJ:tomdale.net/+&cd=1&hl=en&ct=clnk&gl=us http://webcache.googleusercontent.com/search?q=cache:cPuIbiv...

And here is Tom Dale's reply: http://tomdale.net/2015/11/javascript-frameworks-and-mobile-performance/ http://tomdale.net/2015/11/javascript-frameworks-and-mobile-...

yomism 11y ago

Guy that makes a framework replying that frameworks are good. Aha....

timrpeterson 11y ago
I see what you are doing but, that's not relevant to his point.
pkozlowski_os 11y ago
Well, I believe it is a "good thing" when you believe in what you do and got arguments to back up what you believe in.
- btrask 11y ago
  Advocate something you do: cynical self-interest Advocate something you don't do: hypocrite
talles 11y ago
Guy that makes a framework thinks that frameworks are good. Perfect sense to me.

wwweston 11y ago

> frameworks let you manage the complexity of your application Close. Front-end frameworks are one solution to the problem of managing the complexity involved in making an app. After working with a few of them, I'm not really sure that they're the best ones.

kornish 11y ago
Could you elaborate on what some other solutions are?
- matthewtoast 11y ago
  I'm not the parent commenter but here are a few that come to my mind: - Functions - Abstraction - Modularity - Design patterns - Programming paradigms - DSLs - Conventions for naming/formatting/arrangement Although I grant that any of these could possibly work even better when codified into a framework.
  - collyw 11y ago
    Frameworks will be implemeting a number of these for you.
- solidr53 11y ago
  Microservices

lhorie 11y ago

(Disclaimer: I'm the author of Mithril.js) Is it my impression or is Paul on some sort of a crusade to downplay the dev ergonomics of React and try to convince people that it's "slow"? TodoMVC benchmarks have been done before: https://github.com/pygy/todomvc-perf-comparison https://github.com/pygy/todomvc-perf-comparison . So sure, there's room for performance improvements in mainstream frameworks, and React is not the fastest thing in the universe, but come on. Maintaining a large project in vanilla js is largely equivalent to writing code in assembler when there are good C compilers: it's doable, and required in a handful of situations, but not really wise for 99% of real world projects. Re: Tom's response: Something that he didn't mention (which is not surprising since he's an Ember dev) is that frameworks do sometimes detract from end user experience by imposing "opinionated" complexity and assumptions that might prevent devs from doing certain specific things and settling with suboptimal UX - the old adage of "if you want to deviate from the holy way(tm) you're on your own" I'm kinda in the middle of the two opinions: it's definitely important to have access to the "metal" (both in terms of actually being able to code against low level APIs, and in terms of the amount of effort required to wade through framework abstractions in order to get there), but even using vanilla js, a complex app does need a "framework" (in the sense of having rules for where things should be and how they should interact with one another, and in the sense that any non-trivial app will have "library-level" plumbing). So, why not meet in the middle and use a lightweight framework that does 95% of things well enough to actually be used in non-trivial mobile apps[1] but that doesn't have high enough byte count to be bloated? [1] http://en.lichess.org/mobile http://en.lichess.org/mobile

untothebreach 11y ago

Seems to have gotten the HN hug-o-death, so here is the cached version: http://webcache.googleusercontent.com/search?q=cache:cPuIbivGESIJ:tomdale.net/+&cd=1&hl=en&ct=clnk&gl=us http://webcache.googleusercontent.com/search?q=cache:cPuIbiv...