This past weekend my employer was kind of enough to foot the bill (and I was kind enough to sacrifice a weekend) for the No Fluff Just Stuff conference, 2 1/2 days of lectures on various topics. The emphasis is a bit more Java and fullstack than I try to be these days, but there was still a track for the front end, especially Angular.js and other js toolkits.
Two of my favorite takeaways were technologies that are not quite ready for prime time (Or to quote William Gibson: "The future is already here — it's just not very evenly distributed.") One is a tidbit from ECMAScript Next, the flavor of Javascript that should be running in your browser in a year or two.
10 years ago, I was blogging about a weird asymmetry in Java and most other C-derived languages (I know C didn't originate all of these things, but it certainly popularized it) - the unit of subroutine is a "function" which (probably because of its mathematic roots, or possibly because of what it's easy to make a compiler do) can take multiple parameters in, but can only return one thing. Perl, for one, didn't have that problem. A subroutine could have a return statement like
return ($result1, $result2);
and a bit of calling code could easily grab each argument in a named variable:
($thing1,$thing2) = mySubroutine("foo","bar");
In fact, Perl uses this kind of in-array-variable-naming in lieu of traditional named parameters, so while C/Java/Javascript has something like
function myFunction(String arg1, String arg2) {
Perl relies on a special variable "@_" to be the array of arguments, so a similar subroutine might start
sub mySubroutine {
($arg1,$arg2) = @_;
It turns out that "in-array-variable-naming" has a formal name, and that is"destructuring", and it's going to be part of the next generation of Javascript! In short, a function could return an array (as it can now) something like
return [result1,result2];
but in the future the calling function could be doing something like
let [thing1, thing2] = myFunction("foo","bar");
("let" is another bit of the new hotness, with easier to understand behavior in terms of scoping relative to "var". There are some neat syntax for packing up arrays, destructuring objects (vs lists) and what not as well.)
So that's pretty hip.
The final seminar I attended was on Web Components and Polymer. These are a kind of awesome way of writing your own tags to extend HTML5 - for example, you might include a Google Map as a single set of tags, or a chessboard display, or one of a bajillion bits of functionality. Each component gets its little shadow DOM, so conflicts in CSS and the like are avoided. (Polymer is just one implementation of the emerging WebComponents spec, but it seems good at using a "polyfill" technique to bring legacy browsers into the fold.)
I'm not quite sure why Web Components feel like the obvious future to me, and the Right Thing, when Angular.js feels like a weird, gratuitously complex set of kludges. I thought "making up our own HTML5-ish syntax" was one of things I hated about Angular, but I guess if you get the syntax and scoping cleaner, it's a pretty cool thing.
(https://www.polymer-project.org/apps/topeka/ is a nice demo of some of this flexible future.)
Still, I don't feel 100% at ease with Angular's "monitoring mapped memory to drive DOM changes" paradigm, its sometimes arcane syntax (oh, inject your dependency by an array consisting of a bunch of strings and ending with the function that does the work!-- though the conference pointed out how this is a pattern of protecting against "uglify" scripts that might try to rename globally shared variables), infamous learning curves, pushing of its own flavors of paradigms (ala factory vs service vs provider), extensive folder structures, etc etc -- or the way that Angular 2.0 promises to bust through some of the unfortunate syntax issues by making all your old code obsolete.
All that said, Angular might be the best bet in this direction that's here now, and I'm glad Web Components has shown me some of the light about getting into named components, not just an infinite future of <div> decorated in jQuery...
PS Another cool site is http://todomvc.com/, that walks you through the same basic example in a host of Javascript MV* frameworks...
No comments:
Post a Comment