4 ms·

• Patterns (FRP, RP, etc) • Ecmascript 6 • Frameworks (React, Ember, Angular are the big three) Beyond that, it's important to understand the pain points tha

• Patterns (FRP, RP, etc) • Ecmascript 6 • Frameworks (React, Ember, Angular are the big three) Beyond that, it's important to understand the pain points that people are trying to solve. For instance, why is React a better approach to front-end UI's than MVC? Is JSX a reasonable approach to the DOM, and is it worth breaking conventional wisdom? What problem does Facebook's css-layout solve? What issues with modularity and reusability are people trying to solve, and how is this different at different scales of complexity? What's the "why" behind the changes to ES6? And even beyond that, look at the future, and see what people are trying to solve that nobody has quite solved yet. In other words, don't just understand what you can do with Javascript, understand what hurts and how people are trying to fix it, or at least make it hurt less.

peterchon 12y ago
It's really weird to me trying to do a lot of data handling on the front-end side rather than using server-side.
- Bahamut 12y ago
  I spoke to one acquaintance about this after he told me that for his team, they are doing the calculations on the frontend mostly - his explanation was that it turned out to be too unperformant to cache precomputed values in a remote database (and even in IndexedDB) and pull them out (his company does a lot of work involving heavy data analytics & visualizations).
  - michaelchisari 12y ago
    Especially considering how fast even the slowest computers of today are, the client-server architecture gives us the option to immediately decentralize calculations across all clients as needed. It's an easy optimization that's hard to give up, but does present it's own challenges.
- mambodog 12y ago
  You should usually be doing 'data handling' wherever results in the best user experience. Persistence and calculations which are essential to the integrity of your application's data obviously need to be done (or at least validated) on the server, but if the application has any kind of complex workflow then constantly going back to the server to generate new application states is likely to severely bog down that workflow.
the_dominator 12y ago
Instead of learning Angular, learn Meteor, React, and/or Ember. Just trust me on this one..

peterchon 12y ago

It's really weird to me trying to do a lot of data handling on the front-end side rather than using server-side.

Bahamut 12y ago
I spoke to one acquaintance about this after he told me that for his team, they are doing the calculations on the frontend mostly - his explanation was that it turned out to be too unperformant to cache precomputed values in a remote database (and even in IndexedDB) and pull them out (his company does a lot of work involving heavy data analytics & visualizations).
- michaelchisari 12y ago
  Especially considering how fast even the slowest computers of today are, the client-server architecture gives us the option to immediately decentralize calculations across all clients as needed. It's an easy optimization that's hard to give up, but does present it's own challenges.
mambodog 12y ago
You should usually be doing 'data handling' wherever results in the best user experience. Persistence and calculations which are essential to the integrity of your application's data obviously need to be done (or at least validated) on the server, but if the application has any kind of complex workflow then constantly going back to the server to generate new application states is likely to severely bog down that workflow.

the_dominator 12y ago

Instead of learning Angular, learn Meteor, React, and/or Ember. Just trust me on this one..