Discover different ways of doing things by experimenting in debugger, not needing to stop whole application.
Everyone has browser – no installing of programs written in JS.
In early days, it really sucked to debug JS.
Debug.js – implement debugger in the browser.
Hiding is good for production, but bad for playing with code.
With dynamic languages, monkey patching is very easy to try new things.
In development – make (top level) classes and objects to the window to be accessible from console.
Do not left project in broken stage to keep you motivated.
Debugger is the playground. Then take your learnings and dump them into code.
Live edit to fix small mistakes, typos, …
It is impossible to keep entire vast project in your head and step every line of code in debugger.
Break on method call.
You often have more event system in the page at the same time – Node (Browserify), Backbone, jQuery
Dom changes happens async, but call stack is available in Chrome Canary.
$0 $(selector) monitorEvents(elem) getEventListeners(elem) debug(fn) – set breakpoint on function monitor(fn) – log on function call
Live edit problematic with build step.
Trying to solve live editing
flo – live edit js, css, images.
Facebook uses ES6, CommonJS.
Motivation – easy small alterations without reloading app, from your favourite editor.
eg. title capitalisation
History will judge our efforts.
Copy unchanged code, pretty print new ones.
12 seconds vs. weeks on mundane human work.
It’s hard to upgrade codebase, eg. from Python 2 to Python 3.
How can we quickly switch to ECMAScript 6?
async functions is next step.
We can test future right now.
Always be transpiling. Avoid Python 3 trap.
Fucking smart guy!
Pagerduty – alerting tool for oops team, integrate with services, when monitoring tool says something, it will direct it to right person.
You have to make a crazy amount of choosing considerations before writing an app.
Build process itself has dependencies.
It’s common practise to include built files in repo.
Do not make consumers of your package be aware of all the crazy things you have to make to build a library.
Github Releases – connect tag in Github with binary files.
Declare your own HTML tags specific to your domain. Describe them via HTML, CSS and JS.
Standard vs libraries (React, jQuery UI).
Polymer – JS library, that polyfills custom elements spec.
Build anything from a button to a complete application as an encapsulated , reusable element that works across desktop and mobile.
Know when to apply them appropriately.
In UX, flow is same important as individual screens.
Moving routing from server to client.
On the web, users are controlling the flow of app (unlike native apps).
Components are part of bigger architecture.
Isolated – reinforces reusable.
Extensible web manifesto – explain priorities on developing new standards.
Expose low-level capabilities that explain existing features, such as HTML and CSS – allowing authors to understand and replicate them.
Data-bound elements – first in plain HTML.
Ember uses RSVP as promise library.
async function will understand promises natively.
Web-components help us bridge ecosystem, eg between Ember and Angular.
Use your dev skills to improve different things.
Issues – websites are made very poorly,
Test scraping on your own website.
Days of research into seconds.
Deep neuro-network – which artist made this based on the style.
“Obviously same” is hard for computer – image analysis.
Definition of cool is subjective :)
Constantly make forward momentum, even for side-projects.
Behaviour spread from person to person. In programming, idioms are also spread.
On a Github issue, always syntax issue come up.
Programmer love exploiting the system, especially true with “weird” language as JS.
Syntax can spread organically.
Daily workflow, dev lifecycle.
All other steps then development iteration should be automated.
Do not add complexity to development environment.
Website is a dependency graph.
Build system you should not worry about.