Oh, not a keynote, simple overview Felipe de Albuquerque Accessibility and JS: side-by-side I get what they’re trying to do here, I just don’t think it’s being executed well. Kate Hudson Beyond Responsive: Building a mobile web you’re f*ing proud of The web is broken (pause for shock and awe) Native is better at basic operations Native was built with solving these problems in mind Recent blog post: give up on the mobile web, go Native Reasonable rationale argument PHP 5.0 (box.com was built this day, … I kid I kid) Everytone told the lead dev it was a terrible idea “If amazon can do without JS, so can you” First rich client expierence You are here because of a massive hack Test new features before their time Like app cache but not shitty If you’re not doing it, you should. This is not controversial stuff Browser level file storage The third level of hack: Blow shit up Hack together your own user-agent Mozilla first shots at trying to build a mobile app Building a hybrid app better Puts latest chromium in android so you don’t fight with native Browser Using react to render views Simple to save initial state in android Using Android to handle routing More stuff on using javasript in android development Not totally caring, but whatevs … that’s cool Making Relational Cool Again: Javascript on ACID Bringing SQL and JS together Promises kind of structure in a query language kind of way Here we go again with parse, falcor, etc Snapshot state of the world Prevent others from altering data you’re working with (locks) register user, give them id, send registration to service, create a bunch of rows Takes care of standard sql queries for you can write raw sql when you want Shared models sound great, but not great in practice KNEX and Bookshelf not the first to do it Larger scale/stack implementation Node: a target for traditional “CRUD” web applications ES6 -> ES2015, ES7 -> ES2016 Rolling into browsers (observe) How do we make async easier? arrow function are an improvement but we can do better Block until request comes back what if we want to wait instead of Blocking we quicly end up in the “pyramid of doom” function * getStockPrice ( name ) {
var symbol = yield getStockPrice ( ticker )
} A generator function can return multiple values function * getNumbers ( ) {
yield 23 ;
yield 52 ;
yield 22 ;
return 18 ;
}
var iterator = getNumbers ( ) ;
console . log ( iterator . next ( ) ) ; Generators allow feedback Symmetrical support for async and waiting ES Feature maturity stages What if you want to wait on multiple values All ES6 collections are iterable for( var x of [23,2,34] ){..}
Waiting on values with for…on for(var price on new WebSocket(”prices ” + stock)){
…
}
Unfortunately there’s a problem No standard observable interface observer.next(30); //… etc etc
In a perfect worl all push APIs implement Observable If an async function returns a promise and a function* returns and iterator What does an async function* return? http://github.com/jhusain/asyncgenerator
bad dependency management Leads to copypasta and hard to maintain Almost a real language but not quite Walkthrough of different preprocessors and their shortcomings Right, flashbacks of VJeux’s talk for React and whatnot Simple function to turn JS into CSS text Leverage npm to store reusable style packages! Can now use Math.random in styles Async logic to build styles Use JS to insert polyfills build browser specific rules Mutations in Relay (Laney Kuenzel) Big Problem that neither react nor flux solve data fetching Child data component needs are leaked upwards to the Parent this means changes have to propogate upwards and neccessitate changes all the way up the tree to many files Data fetching on the server and rendering on the client Run into scenarios where you’re over-fetching Sending data you don’t need Or worse, under-fetching and the page explodes How would this work in a perfect world? Have data fetching objects reside in one place Where you execute you rendering, within the react components GraphQL: Put the data query in the component Component describes it data needs Think layer to interact with the server Can be wrapped in other GraphQL queries One single store for dealing with graphQL data Single store provides lots of benefits
Easy to build things like pagination
As data is related to component, devs can work indepent of one another on different components Suports writes as well as reads. Data you want after mutation Want anything that could’ve changed as a result of the mutation returned from the Mutations Can detect dependant mutations Will wait for one payload to return before dispatching another Already being used in production in a couple places at FB Oh crap, announced somethign new still in development … totally zoned out Main goan when designing Relay Find common patterns taht are causing issues Optimistic updates in the queue By using relay you get these problems solved “for free” Mariko Kosak - Knitting for Javascripters knit stitch vs binary stitch Can’t believe I just wrote that as a note
There’s a github for Knitting Took knitting patterns from that and turned it into JS Fun knitting “bugs” caused by ruffles MIT paper actually covering this with crochet Using Node to pixelate and translate images Pretty solid, always curious how to create depth in 2-tone Set up a basic atari style missle defender game Creates chaos, browser starts to jank Call the function when browser is ready to paint No gaurantee we’ll get called 60x / second Amazing animations in his slides, worth mentioning Solid speaker too, enjoy how he’s telling a story Big advantage is you can scale it easily gives us best of both worlds Reminds me of the eloquent javascript nature sim Amazing war sim set up, sets the params and just lets yellow and blue sides go toe to toe walks through code behind each element, how it moves how it decides to attack this is fucking ridiculous Naveed Ihsanulla - Parallelism experiments in JavaScript concurrency vs Parallelism Evolution of the Web applications breif hisotry, evolution of js, web apps nowadays, etc At a bit of a bottleneck with CPU speed We’re just adding cores now Leads to us waiting on operations to completed Each appication type has it’s own type of issue bit heavier than system threads Concurrency already exists in JS Limitited to no-shared-state computation not dependant on event loop implementation versatility support applications and alogrithms based on threads pthreads support extensible web philosophy posts giant spec to scare everyone off err, rough examples ensue this feels pretty close to the metal Chris Lorenzo - Polymer: The future of Web Components Hey I remember polymer, let’s see what they’ve done with it Looks like netflix did a couple years ago Okay, nothing new so far, we knew all this when polymer was released Okay buddy, easy on the kid pics
