Here is the last part of CascadiaJS Browser Day.
Tessa Thornton: Components are the future of the web: it’s going to be okay
HTML doesn’t always represent content e.g. select list options pulled using JS, range input field.
Declarative API: declarative specifies what the desired result is and leaves the implementation up to something else (e.g. SQL uses algorithm, but you don’t decide which algorithm) vs. imperative which specific the steps to achieve desired result
HTML has declarative APIs e.g. range input field.
We think our HTML should be dumb, but then we have to do all sorts of things in JS to make up for it.
Declarative are reusable, composable. Web components in combination with polymer.
Limits to declarative programming: need to tweak implementations. Up side, declarative API, meaningful HTML , encapsulation, reusability, composability, choose your components.
Coming whether you like it or not.
Andrei Kashcha: A story of graphs, package managers, and one million vertices
Every visualization starts with requesting an animation frame, which is just a browser API. It takes one unction and calls it again and again.
Using 3GS, which is built on top of WebGL, but will hide it behind an interface.
Code example with particles.
How do you render graphs on the screen?
If render nodes at random, you end up with a mess. Hard to understand because there’s no structure.
- reduce amount of intersections
- connection between two nodes have same strength, should have the same length
- detect symmetry
How do you combine all of these? Nature has that answer.
If pretend every node is a charge particle, they will repel each other. Pretend every connection is a particle spring. These two competing forces pull them apart and on the other hand make sure they don’t fly too far away.
How to we make sure that it still renders quickly?
Put it on the server will calculate the forces for each particle. Save the results for each note with the coordinate.
You can render really, really large graphs.
Using Bower to map package dependencies. Only showed dots, didn’t draw the edges, because it will otherwise will be beautiful but useless.
What if only render the links who’s length is only smaller than 200px or 100 px?
Can begin to explore clusters of dependencies.
Try it: http://goo.gl/yRdHjE
Works even with 200,000 packages.
It is Fast
Runs at ~60 FPS.
Can deal with large sets
Visualizing GitHub users 1.1+ million nodes, about 20MB of data.
Ashley Williams: If you wish to learn ES6/2015 from scratch, you must first invent the universe
I like to think about thinking, especially the type of thinking that happens when people write code.
“The effective exploitation of his powers of abstraction must be regarded as one of the most vital activities of a competent programming.” Edsger W. Dijkstra
When programming, you’re abstracting.
“Each significant piece of functionality in a program should be implemented in just one place in the source code. Where similar functions are carried out by distinct pieces of code, it is generally beneficial to combine them into one by abstracting ou the varying parts. ” – Benjamin C. Pierce
“… immaterial to the problem being solved.” – Wikipedia
“The real problem in speech is not precise language. The problem is clear language… ”
Where Should We Begin?
There are things in our languages now that will go from “draw two circles, draw the rest of the owl.”
Abstraction can be more efficient, but being more explicit means more maintenance.
Human beings are amazing pattern recognizers. See the patterns, give them names. This is abstraction.
We need to be careful about the abstraction we makes, because it will cause big problems.
“ECMAScript syntax is relaxed…”
Objects are not fundamentally class-based. You might not need class syntax.
“… The practical question is how wrong do they have to be to not be useful.”
strucutre, heaviour, and state are all inherited.
Teach Programming Concepts, not Language Features or Syntax
Programming languages are tools. There isn’t a bad language, just a good programming language for the job. Start with a simple language, and then extend the language gradually.
The Creative Extension Principle
Implement things only when we need to, not just because we foresee it.
Think About This
Are we programming yet? What do we mean by programming? If what we mean by programming is really this awesome feeling of abstraction, how much time do we spend doing that instead of typing into our terminal?
Need to think about what our paradigms our.
Let’s reconsider our ontology, do it often, and stay beginners.