• Personal debugging workflow
  • Don’t Write Bugs!
  • Although…
  • the opposite is true
  • the artifact of writing software is fixing bugs
  • gives you experience
  • no silver bullet to debugging
  • you need to pick and chose the right tools
  • debugging helps you to identify issues earlier
  • Disclaimer 1: Frameworks?
    • Don’t have a project that required frameworks.
    • Tools I use are not for frameworks
    • For react: It brings it own debugging tool, because it has to as it is so abstract.
  • Disclaimer 2: I rarely do x-browser testing
    • Current work is not requiring it, mostly doing JavaScript
  • The art of debugging (says wikipedia)
  • The parts to debugging
    1. Replicate
      • Hardest and most important part
      • Bug report: Saving doesn’t work.
      • I know saving works.
      • But it doesn’t work for them.
      • Wontfix is no solution.
      • Litmus-Test to see if it happens at the URL that the user is using.
      • Likely: Series of event happens to the bug
      • Debugging is the end of the process, it should have been caught in tests, right?!
      • Caching and browser add-ons mess with pages
    2. Isolate
      • Pair down to the simplest form where the bug occurs
    3. Eliminate
      • That makes fixing the bug much easier
  • But what is if you have a Heisenburg bug? (A bug that changes its shape while you’re debugging.)
  • Clean the environment as much as possible
  • State
    • All debugging comes out of state.
    • Two types: passive state
      • What happens?
      • Literally looking how the canvas was built
      • Memory history.
    • Interactive state
      • Fixing in the browser to not lose context
      • no back and forth to the editor and back
    • The stack
  • Two methods:
    • Inside out
      • When something changes and you have no idea where in the stack is the error introduced.
    • Outside in
      • You know where the bug is and you go in and edit the file.
  • You can import your local source in the Chrome devtools debugger and link it to the running files
  • Timeline mode is also useful to find performance bugs
  • DOM breakpoints allow you to stop the script when an element changes and shows the code snippet
  • Debug memory leaks with profiles. The memory should be on the level where it started. Snapshot help
  • Red background in profiles: Garbage collection didn’t work out right.
  • There is no silver bullet!

  • Lots of old techniques out there have been outdated.
  • Layout methods have not.
  • Still using the same techniques as we did years ago.
  • Increasingly we’re using frameworks.
  • Add markup.
  • CSS processors.
  • Hopes for layout:
    • Flexbox
    • CSS Grid Layout
    • Box alignment module
  • Give us source oder separation from visual layout
  • precise alignment control
  • relationships to each other
  • Remember Faux Columns? (2004)
  • people jumped at display:table; give us a relationship between columns
  • Separation of content and markup
  • Separation of source and display
  • A bit of a failed promise
  • Need compromises, usually
  • Flexbox and Grid Layout helps to display items in every order
  • Default positioning
  • grid-auto-flow helps to fill gaps maisonette.js style
  • Kind of scary, especially if you think about accessibility.
    • Got a lot to learn
    • Good = Creating the best source with the best markup and then displaying it best for the breakpoint
    • Bad = So, I don’t need to care about the source order
    • Terrible = Flattening out the source order and do everything using CSS grid and flexbox
  • Relationship of the items but independent from source order
  • Control of alignment
  • Box alignment module level 3
    • flexbox alignment to use for other specs
    • VERTICALLY CENTER ALL THE THINGS!
    • Distributed alignment
      • justify-content
      • align-items
        • stretch
        • center
      • justify-self
      • align-self
    • In CSS grid layout
      • Chrome canary
      • align-items center in a css grid with repeated columns
      • instead of stretch
  • Responsive by default
    • Flexbox:
    • CSS Grid:
      • fr (fraction) unit – similar to flex grow
        • grid-template-columns: 1fr, 1fr, 1fr -> same width
        • grid-template-columns: 600px, 1fr, 1fr -> remaining space is shared between column 2 & 3
      • grid-template-areas -> ASCI Art building of layouts
  • But what about old browsers?! I can’t use that stuff!
    • We must to cater for the web of today, but we need to look forward and use progressive enhancement.
    • No layout is not an option.
    • Need to think about feature support differently in a world of evergreen browsers.
    • Business case: How long will the website that you build right now be active, the site will be updated when users upgrade.
    • CSS Grid Layout
      • Early implementation in IE10,11 & edge
      • Current spec in Chrome, Opera (experimental flag)
      • Prefixed in Webkit Nightlies
      • Partial in Firefox Nightly
      • In near future
      • High priority on edge
    • This is not all or nothing. You can begin with small UI elements, use the modern methods for finessing
    • Flexbox in the real world: Zoe M. Gillenwater Enhancing Responsiveness With Flexbox
    • Check stats and compare feature support, for example that is supported by gaug.es
    • Separate mobile and desktop stats – mobile might be more advanced
    • Use such tools for prototyping – you learn how they work, and you immediately can work with it while it is developed
    • You can give feedback to the Working group and it has an effect and they get implemented.
    • It is too late to comment when the things are out in browsers. If you want to be involved, do it now.
    • gridbyexample.com
    • Slides & more information: https://rachelandrew.co.uk/presentations/css-grid

  • You can generate audio using JavaScript
  • Tiny new language
    • small vocabulary
    • few grammar rules
    • couple of ideoms
  • AudioContext
    • like canvas
    • toolbox
    • instance factory
  • Nodes Taxonomy
    • Generation
    • Manipulation
    • Analysis
  • Audio Context as audio graph
  • Modular routing
  • Sound modulation
    • connect() helps you to modulate from one node to another
  • Gain nodes
  • Don’t keep nodes
  • stop and disconnect sound sources
  • load binary data
  • decode into a buffer
  • create buffer source and use it
  • you can even bend the pitch of the audio live
  • place sounds in 2D space – StereoPanner
    • Place to left change pan attribute to -1, to right to +1
  • For 3D space, for example in Games, use Panner
    • update position for accurate placement
    • tries to be realistically physical, so the unit is meters
  • BiquadFilter
    • Let certain frequencies pass
  • Analyser for Visuals
    • Real time frequency and time-domain information
  • Getting creative
    • Real time input + processing
    • Get user media + echoing
  • Web audio is minimal and powerful
    • many built-in nodes
    • one graph, simple connect rules
    • sound generation, processing and analysis
    • great for games, VR and interactive applications
    • it’s also fun!
  • Web audio meetups in London & Berlin
  • Slides: github.com/sole/howa

  • Lets compare tooling to plumbing
  • new type of fitting: Sharkbite
    • Lego for plumbing
    • snaps together instantly
    • can connect any material to copper
    • can be redone
    • less prone to leaks
    • more expensive
    • less error prone
    • plumbers: too expensive, too new
    • changes the industry competely.
  • Some people write off tooling as over-engeneering, others see the benefits
  • Fine line between tooling for tooling’s sake and tooling to get work done
  • Let’s be smart about the tools that we’re using
    • Investments need to pay beck
  • Overwhelmed? Crying? 😭
  • This talk: 😭-> 😃
  • Build tools:
    • biggest barrier to entry
    • a lot
    • what are they for
    • compiling + converting styles
    • concatenation
    • test running
    • deployment
    • anything, really
    • two big: grunt, gulp
    • npm as a built system by using the CLI commands directly using scripts in the package.js, takes bash
      • But probably best used with simple sites
      • hard to maintain
    • Webpack
      • javascript modules focused – gulp meets browserfy
      • bit of a hard to learn api
      • react community likes it
    • What should I use?
      • Pick one. Whatever is best for you.
      • Personally like gulp
        • built speed
        • packages available
        • easy to understand and author
        • overall industry acceptance
        • 47% use gulp, 20% don’t use anything
      • Sass brought people to the built train
  • Performance
    • Critical: First paint is important
    • Purify: Removes unused CSS
      • Looks at JS and CSS and finds unused CSS
      • Much smaller CSS files
    • ImageMin: common interface to 17 different image compression libraries
      • Recommendation: MOZJPEG
    • Uglify.js: Minifies, compresses and mangles code
  • Dependency + Module Management
    • We’re seeing a huge shift on how we manage frontend dependencies
    • Problem: Many scripts, duplicated, different versions of the same file
    • The solution: Modules for javascript
    • How does it work
      1. Install your libraries, ex. npm/bower install jquery
      2. Write your code, ex. var$ = require(‘jquery’); or in IE6: import $ from jquery
      3. Compile into a single or multiple bundles
        • Browsify – simple, quickest setup
        • WebPack – handles css
        • JSPM – client side, close to JS spec
      4. Stop?! What about Gulp/Grunt?
        • They are task runners, one of the tasks will be “bundle javascript”, they can call those bundlers.
    • Small modules that do one thing, and one thing well
    • Only need ajax, npm install fetch
    • Pick and chose from lodash
      • Is coded in a way that you can access all methods individually, exports only that module to use
    • NPM or Bower?
      • Libraries, similar
      • NPM for everything!
      • Ecosystems coming soon to NPM, helps categorize the modules
  • The Future
    • JS + CSS evolve rapidly
    • Don’t need to wait with future code today
    • Wasn’t possible before
    • JavaScipt
      • ES6/7/Next
      • Arrow functions
      • let and const for variable declarations
      • template strings
      • many more
      • Babel
        • Allows you to write IE6 code but will then compile it to code that will work today.
        • gulp-babel
        • What about new language features?
          • polyfillable require babel/polyfill
    • CSS4
      • Everyone 😍 SASS, comes to browser
        • Nesting
        • Scoping
        • Variables
      • CSSnext allows to write in CSS4 and compiles to CSS3
      • part of postCSS ecosystem
      • quantityQueries helps to work with those, also a postCSS plugin
  • Workflow treats
    • Browsersync – like live reload but actually works
      • Instant reload
      • Includes server with cert for easy local HTTPS
      • Proxies existing applications/servers: Wordpess, ruby, python
      • Exposes server via local IP, can test on multiple devices
      • Syncs clicks, submits, scrolls
      • MAGIC
    • Sourcemaps
      • Code goes through several transforms before it is in the browser
      • If there is an error that needs to be traced back
      • Sourcemaps is standardized
      • Can be used with a lot of plugins
  • Tooling is extremely important
  • Everyone should have  built process
  • Sky is the limit
  • Better code

  • Simplicity is not dumbing down.
  • There is room for creativity even in relatively simple things.
  • Let’s focus on what matters.
  • Helps to provide the right optimizations for users.
  • Benefits about static sites
    • cheaper, simpler hosting
    • fewer points of failure
    • fewer vulnerabilities
    • easier compliance
    • greater portability
    • sandboxed environments
    • attrition avoidance
  • Credibility of static sites
    • Just for simple things? That’s not the case
    • Campaign for Obama – $250 million dollars donated
      • Static sites perfect for large audiences
      • baked with jekyll
      • large audience
      • rapid iterations
      • hosted statically
    • Google project
      • Content on Github
      • baked with jekyll
      • served staticly by google
      • Reduced risk
    • Google year in search
      • Annual retrospective
      • large audience
      • infrequently updated
      • long life
      • 40 stories, 52 languages
      • 2.6B social impressions
      • content abstracted
      • baked with “goro”
      • served staticly by google
    • Static sites are already mainstream
    • Enablers:
      • Front end tooling is a key part
      • Generators and templating -> staticsitegenerators.net
      • Style guides as a side effect… as an artifact… as a process
        • Styleguide driven development
        • How to have a style gide as a secondary output for your site
        • Modules + Templates + Content built site through generator
        • Style guide also built there
        • Unless a style guide is part of your built, it is just more documentation to maintain
      • Automation
        • Gulp grunt, brunch, belch, burp, cough, sneeze ;-)
        • deploy faster, safer
        • update faster
        • feels dynamic
        • surge is good tool to do this deploy
    • We need a developer mindset and people want to manage content themselves.
      • traditional web development is very complex with dev, staging and live stages
      • also server side logic
    • Static sites are simpler
      • Dev environment: Site generator & build tool -> Production -> User
      • Content as a service that cares about the admin interface.
      • Additionally you could use deployment as a service
      • Is that simplifying?!
        • It’s about shifting/outsourcing complexity. Distance between user and complecity.
        • Source content at build time, not execution time
      • Jekyll data
      • contentful is Content Management as a Service
        • Hosted CMS interface
        • Exposes content via an api
        • Supports translations
        • user roles & management
        • Environments & versions
        • Decouples content administration from the production invironment
        • integrates into jekyll: jekyll-contentfull
      • roots.cx
      • netlify for deployment
        • commit hooks
        • command line interface
        • portable configruration, can be in a config file in the repo
        • notification
        • control of headers
        • basic auth
      • A lot of control
    • Limitations:
      • personalization
      • very very large sites
      • user generated content
    • Need to find the best fit for the project
    • It depends
    • http://bit.ly/ssg-hollywood