Here is the last part of CascadiaJS Browser Day.
Tessa Thornton: Components are the future of the web: it’s going to be okay
Web Apps started with just HTML, but then JavaScript grew up, AJAX was introduced. Separation of concerns: HTML for content, JavaScript for behaviour, CSS for presentation and called it best practices. Decided best practices were killing us because not feasible in a lot of situations.
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.
JavaScript in the future: back and forth between wiring together components and tweaking implementations
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.
Several methods:
- 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.
Mobile?
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.
https://github.com/anvaka/pm
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.
Abstraction
“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
What problem are we trying to solve with JavaScript?
For beginners, iteration is hard. Many say that programs should be written for people to read, and only for machines to execute. Taught iteration in a language that they did not understand. JavaScript version exposes the underlining concepts of iteration in its syntax (vs. Ruby where it was abstracted).
“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.
JavaScript has been a delightful beginner programming language because it lacked abstraction, but that’s all about to change.
ES6/2015
“ECMAScript syntax is relaxed…”
What is JavaScript trying to solve?
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.
Classes are normally thought of as blueprints. JavaScript classes are model homes. You can leave them empty but someone can move in.
What even is a class? In JavaScript, we may be trying to do too much.
Teach Programming Concepts, not Language Features or Syntax
JavaScript is a teaching language, and will be the introductory language to a whole generation of programmers.
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.
We have an awesome opportunity to think about how we extend JavaScript.
Let’s reconsider our ontology, do it often, and stay beginners.
End of the Day
Time for a quick nap perhaps before dinner.
Thanks for joining today and come back tomorrow for CascadiaJS Server day!