Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Present and Future of Front End Development in ...

Max Bucknell
November 15, 2016
780

Present and Future of Front End Development in Magento 2

Presentation given at Mage Titans Manchester, 12th November 2016.

Max Bucknell

November 15, 2016
Tweet

Transcript

  1. We Hold This Truth to be Self Evident Front end

    development revs itself faster than Magento can rev its front end framework.
  2. So Why a Front end? Magento ❤ the out of

    little "Mom & Pop" shops.
  3. Developer Experience Decrease time to build things. Make developers love

    working with your platform, or at least not dislike it. Minimise WTFs/min
  4. ES6: What? import $ from 'jquery'; const component = (config,

    element) => $(element).hide(); export default component;
  5. ES6: How? Compilation to "normal" JavaScript, for browser support. Handled

    by a tool called Babel, easily integrated into Grunt/ Gulp.
  6. ES6: Why? It's a better language, and it represents the

    future. For a moderate increase in build complexity, you get huge benefits in language niceness and sensibility.
  7. Performance Magento is okay, certainly a huge improvement on
 Magento

    1. Best practice: Use AJAX for all customer data, to maximise varnish usage.
  8. Capability If not state of the art, is it at

    least possible to build ambitious things? Yeah, it is actually. So what’s the problem?
  9. What to Do Documentation, training, building expertise over time, killing

    old habits. Magento need to adopt their own best practices.
  10. Security What’s next for the future of web security? What

    do we need to do? What does Magento need to do?
  11. Sub-Resource Integrity: What? <!-- Run only if the file matches

    the hash --> <script src="..." integrity="sha384-oqVu...JwY8wC" ></script>
  12. Sub-Resource Integrity: How? The hash is in your markup, so

    is calculated at build time. SRI checks whether the files you deployed are the ones you are getting. If it's different, it won't run. Your site might break, but your customers are safe.
  13. Sub-Resource Integrity: 99% Build a hash map as part of

    the build process. Serve it on the front end. Use Require JS' onNodeCreated hook to add the integrity attribute.
  14. Content Security Policy: How? A special HTTP header that tells

    the browser from which hosts it can load things. You tell it to only trust the domains you are expecting: Your CDN, tagmanager.google.com, etc. When used properly, it makes XSS much more difficult.
  15. Content Security Policy: 100% Remove all inline scripts. This means

    full migration to JS components, rather than inline calls to require(). Add a configuration field for allowed hosts. Send it as a header in every request.