monfera

> JSDoc _is_ TypeScript

This is surprisingly true in a way. TypeScript is not a language(1), it's primarily a linter-assisting overlay atop of an actual language, JavaScript. Also, there's a linter that outputs and bundles JS, shedding the alien type annotations and also injecting its own, very partial runtime.

So, JSDoc is just a linter/documenter aid. And so is TypeScript.

(1) TS is not a language: it has no spec, no reference documentation. It defines no behaviors, in particular, no runtime behaviors. It sits atop of various JS versions, layering over them in unspecified ways. TS is a linting layer, and also is a hack.

What changed is that the very things capable of eliciting interest in programming also offer overpowering content consumption functions with huge, never ending catalogs of games, movies, videos, short funny clips etc.

As computing and "content" proliferate, the uncompetitiveness of creation, esp. symbolic creation such as programming, is increasing. At some point, broadening of the access no longer offsets this effect, and the talent pool may start to shrink even if capability and permeation is a million times higher than it was.

Good points. A minor thing, generative art isn't necessarily abstract art, though currently almost exclusively is. (Oh and spelled Pollock.) Regarding validation, it might not matter for some, but might for others. I'm sure there were quite a few great artists who wouldn't have done their art at the same level had there not been validation as art. Something more mundane, recognition is likely a big factor in whether patrons seek out and are willing to pay for generative art. So it can matter even for those who aren't looking for the ego lifting part.

In the case of asymmetric competition, a company with vastly more resources might curate a list of undisclosed problems with competitors' products, for when a major event like this strikes, they can drag along the underdogs. The optics are different if 1) the dominant player can pretend it's "working together" with the other vendors, 2) the dominant player condescendingly points out mildly related issues in competitors' product, and 3) the name of the alternatives keeps getting linked in a "we're in the same boat" way.

I'm not suggesting this is the case here at all, as it's unlikely that Intel identified this precise issue with AMD long ago and haven't checked their own vulnerability (though there's always a chance that an issue is found by company A when analyzing the strengths and weaknesses of company B's products, which then turns out to apply for their own products too). But I wouldn't be surprised if somehow there were some loosely related AMD issues that came to light now, and it's impossible to tell if those would be current finds or older ones.

Given Intel's dominant position, they may come out ahead in P&L or gross margin terms even if it turns out to be a clearly Intel issue, as the perceived or real loss of performance may trigger an upgrade spree, sold unit counts inevitably dominated by Intel purchases.

AMD has just started to catch up in overall performance, and in the worst case bug impact to Intel, they may even get competitive single-threaded performance. Also, there has been speculation that Apple has been evaluating ARM processors for some future laptops, and a sudden drop of the baseline is an interesting turn of events.

While this in theory benefits the underdogs, financially Intel may well come out ahead due to their market hegemony.

> Loop-Blinn is fine if you want fast rendering with medium quality antialiasing

For example, when using SVG shape-rendering: optimizeSpeed ? I truly hope that SVG is going to be part of this new magic, and that the shape-rendering presentation attribute is utilized. I don't think current SVG implementations get much of a speed boost by optimizeSpeed.

Speaking of which, to what extent will SVG benefit from this massive rewrite?

I think there are other reasons for dismissing BEM, it's quite an opinionated and shallow structuring, good for some stuff and not for others. Very HTML tag oriented, for which we have, well, HTML tags already. Its claims are simply not true (eg. "Reduces style conflicts by keeping CSS specificity to a minimum level."). Even in syntax, it saves on silly things (".btn"?) and wastes much more on, in effect, introducing Hungarian notation to CSS. I could go on but no time rn

I'd agree with it were it not for the huge difference between the view refresh latencies. Within the browser, it's near-intantaneous. Hot module reloading (which is still experimental) is relatively fast, yet there's a couple of seconds of a trip; also depends on what and how changes. Full page reload can take even longer, there's compilation time, bundling and the unavoidable cost of reloading stuff in the browser. Sure a couple of seconds doesn't sound bad but it's still a couple of seconds longer than what it should be (immediate) and it breaks my (work)flow.

Just adding it here as well: if one likes editing CSS files in Chrome Dev Tools, then activating Workspaces will save such changes into the source file. This Dev Tools integration with the Svelte approach is so useful that it might actually tilt the choice in favor of CSS files over the more abstract, thus Chrome-uneditable CSS-in-JS (Workspaces are doable with SASS too as per https://www.amazeelabs.com/en/How-to-write-Sass-within-Chrom...).

An example may be, graphic designer shop gets a contract to update the company 'style guide'. It gets done and there are a lot changes that are cross-cutting w.r.t. components, starting with fonts, borders, margins, border styling etc.

Also, what's not fully clear to me, what if - as usually is the case - the components are nested? Changing eg. font in the outer component would leave inner components fully intact?

A side note, I'm wondering how the Svelte approach relates to `isolation` in cycle.js https://github.com/cyclejs/cyclejs/issues/259 -

> Leave data processing and business logic to the back-end, on the server

In general, this is not good. Of course there are specific applications where it's useful but in the general space of applications it would be very limiting.

For example, go to http://square.github.io/crossfilter/ and do the filtering on the 5MB data such that you wait for the histograms to be updated from the server. Instead of the tens of milliseconds, it might be seconds or tens of seconds if the server is loaded, i.e. orders of magnitude slower, not to mention unpredictable.

You can think of the network as a data flow constraint. It constrains latency, throughput, privacy and security; the constraints can be unpredictable (network outage; DoS, MiM attack etc.). There can be many good reasons for wanting part of your domain specific logic to fall on the client side.

In particular, dynamic media e.g. interactive data visualization, games and most interactive things that use data or modeling are best partly in the browser.

We're past the point where the rule of thumb was to do business logic on the server and the client only did the presenting of the view and acted as a controller.

Though both are on WebKit, they use different renderers. Generally Chrome is better than Safari except on iOS where Apple forces other browser makers to use the Safari engine, I guess it's one way of keeping tabs on mobile browser speed competition :-)

Interestingly Firefox is often quite a bit slower than WebKit based browsers even if there's not much JavaScript behind the animations, so there may be other bottlenecks.

Even simple SVG geometries (e.g. line sections) take more time to render if there are lots of other such SVG elements off-screen in the DOM. The simplest thing for a time series would be putting in a bunch of <path> elements with long 'd' path strings (and annotations etc.) and just use CSS or SVG transform to show the currently interesting part, but even such a simple use case - ideal and compact from a graphics denotation viewpoint - bumps into performance constraints real quick if you want to pan or especially zoom at 60FPS. This stuff works great with WebGL so I'm coding up splines etc. which all exist in SVG - it's a great standard that would deserve a real fast benchmark and competition among browser makers.

Yes apparently I was on 120% zoom level and therefore it worked on my machine (TM)

Yes SVG is very powerful denotation.

FWIW I prefer my other current example (I'll wrap up a third one soon), procedural map generation and reflection bump map with SVG http://bl.ocks.org/monfera/21be9bb116a8e5b2423b706155fdb718 (click the map or move the mouse) or Nadieh Bremer's examples eg. http://bl.ocks.org/nbremer/0e98c72b043590769facc5e829ebf43f

Also if you want to generate SVG programmatically check out http://d3js.org and https://www.dashingd3js.com/svg-paths-and-d3js

it just uses a setInterval with 100ms so your kit might be able to do more - bl.ocks can be forked with http://blockbuilder.org/search

Google was first with a decent SVG and they were leapfrogged. But Chrome is the most used browser, and together with Safari, WebKit leads big time over the shrinking IE and FF portion. I and my clients can't afford to do entirely different things per browser.

My area of data visualization involves e.g. time series, where a decent zoom/pan implementation and a few years of stock or weather data means that you're juggling DOM elements in and out to keep frame rate, but adding/removing DOM elements revolver style is even more expensive, introducing janks. I also tend to work on exploratory vis where it's useful to scatter all points, tween them (not as a gratuitous effect but for object constancy, to help the user keep context) etc.

Interestingly it's also Google who wants you to get minimal with payload size. Yet it's OK for them if you roll your own speedy version of SVG by bundling a 100k of three.js or make your own text rasterizer, essentially reimplementing browser functionality.

No, SVG is perfect for things like that, and very compact (example coming, or an existing one, check the header image on twitter/monfera). I'm mostly concerned about dynamic visualizations.

Maker here. I meant it as a way of saying good-bye to SVG as for the past years I mostly work with WebGL. A couple of other bl.ocks will be up soon.

It turns out that despite its name, Scalable Vector Graphics it isn't. Sure it's scalable _spatially_ but it's not scalable _temporally_. A.k.a. slow.

SVG only recently became capable of 60FPS (with only a few elements, of course). Until this year, it was capped at ~40FPS.

Also, SVG was meant for graphics and the HTML DOM wasn't. Yet SVG transforms are NOT hardware accelerated, click on Paint Flashing in Chrome Dev Tools / Render: http://codepen.io/monfera/pen/JKOqyY Meanwhile HTML transforms are GPU accelerated: http://codepen.io/monfera/full/qNVzBm/ or http://codepen.io/monfera/full/BzmERz/ (no green rectangles flashing)

There's also a big overhead of just having a lot of SVG elements even if they're presently off-screen (in which case WebGL wouldn't draw it or even if you call gl.drawArrays on them it doesn't hit the shaders).

Having done WebGL I feel that a transpiler from SVG filters to WebGL I could hack together would be an order of magnitude (usually I get an order or two magnitude speedup when moving a plot to WebGL).

Someone at a major browser vendor confirmed there hasn't been significant work on SVG for many years. SMIL is now out. The hardware accelerated HTML DOM, Canvas and WebGL are eating SVG's lunch. I suspect it's one of the reasons the new D3 4.0 adds more separation of concern between logic and rendering, and there's a wealth of Canvas based examples from Mike Bostock and others.

To paraphrase Greenspun's tenth rule: Any sufficiently complicated Canvas/WebGL 2D data visualization contains an ad hoc, informally-specified, bug-ridden, but FAST implementation of half of SVG. And it's sent down the network each time, including mountains of font rasterization.

Indeed, what I like about plotly is that you can start pretty much anywhere (R, Python, Jupyter, browser JavaScript, node.js, Julia, Matlab...) and get to an interactive, explorable chart (disclaimer, I'm working on WebGL plotly functions eg. https://twitter.com/plotlygraphs/status/747879741399568384)

You can generally use them with 'is', for example: <marker id={'bar'} is markerHeight={viewModel.height} refX={viewModel.xCenter} markerWidth={viewModel.width}>

D3 is great for updating / augmenting a server generated chart on the client side, with one caveat. Usually it's good practice to do the D3 DOM binding with a key (similar to the react key, but is a function; second argument to .data()). This allows the proper identification of a data point to be identified when it comes to enter, update or exit. However, with server-generated contents, you don't have the __data__ properties on the DOM elements initially. So, before there's any addition/deletion/update on the client side, it's best to establish the binding and populate __data__. An alternative is, if your use case permits, to not use the key function and work off of DOM element sequence. Either way, the best resource IMO is the GUP I, II, III series from Mike: https://bl.ocks.org/mbostock/3808234

There's also Shiny, Jupyter, Bokeh...

Plotly animations are coming along gradually, and Reactive Vega may be something to look at. Unrelated to these, I've been exploring real-time visualizations (and more in focus, real-time configurability) with D3 e.g. here: http://bl.ocks.org/monfera/35be5626a47110312c35 but Mike Bostock and many of others have technical notes on updating charts, like here: https://bost.ocks.org/mike/path/

I'm contributing to plotly.js right now, which is also declarative, and I see the pros and cons of levels of denotative semantics (mostly depends on goals and library user requirements) but it was just an example for what I mean by more radical changes. Good you mentioned it anyway, protovis -> D3 also represented a rather disruptive change. But perhaps I was late with these questions for this specific AMA.

Fantastic work! D3 has a large API surface area, due to the functionality it covers. So even a relatively conservative major upgrade is a TON of work, and some of it might not have been pure fun only.

1) What's your opinion on the apparent case that the bulk of changes come from you, as society promotes teamwork so much? Is it a case of 'small team efficency'? (Btw. I know of others' contributions too, and reliance on Rollup, ColorBrewer, matplotlib/Viridis etc.)

2) What kept you going? It's probably at least a person-year of work just on your side that's not paid for by companies, not to mention some kind of startup bet. Have you alternatively toyed with the idea of starting a value-added layer, since so many for-profit organizations benefit from your work?

3) While it changes the API, and most everything is rewritten, it's IMO a conservative upgrade in that it doesn't steer away from familiar concepts and structure. It still does DOM binding, transitions, layout etc. fairly similarly. Have you considered much more disruptive departures? As an example, React's DOM diffing is more radically different from D3 selections than the change from D3 3.* to 4.* or the Grammar of Graphics as an API concept is more radically different from D3 than the 3.* -> 4.0 API changes. Or something like moving away from the 'functional objects' concept in favor of curried, fixed-argument pure functions, perhaps prefaced with the familiar chaining API would have been a large change (these are mostly examples rather than wishlist). What were YOUR ideas, had you wanted more disruptive changes, or 'D4'?

The nice thing is that you can mix and match D3 components as needed, e.g. require certain layouts or other pure functions but use React in lieu of DOM binding (if that's preferred for one reason or another) and not use the D3 selections.

I'll assume a render tree with only functional components for simplicity's sake, and no observables, just plain function application:

A full rerendering requires that all the functions be called. Indeed, there's a natural limit to how much data is updated on the screen (well, unless we use canvas or WebGL but I digress) but the render functions themselves may be expensive and wasteful to rerun, especially if there is inferrable knowledge that the nature of the change doesn't warrant a recalc in some branches. Even if it doesn't cause jitter, it may be wasteful on mobile battery.

Why do I think render functions may be expensive? Official React documentation steers people toward having stores that keep 'primary truths' rather than things that can be derived from them via pure functions; and it suggests that these calculations be part of the render functions. It works, it's functional and it's clean. But you potentially run a lot of calculations, depending on the domain. With plain FP, much of this will be wasted as causing no visible change. Not only this, but the needlessly executed render functions do generate virtual DOM snippets; and these snippets do get scheduled for DOM diffing. All these add up to what is, in my experience, a jank-inducing difference. I even introduced memoization, but just DOM diffing alone is significant on a sizeable app (which makes sense as there may be an order or two magnitude difference between VDOM elements that exist vs. ones that really may change).

With observables, e.g. reexecuting a calc or regenerating a DOM snippet, control is finer grained, without the manual and possibly erroneous performance optimization hinting approach known as shouldComponentUpdate. I had cases when blind function reapplication (memoized or not) caused jank on the desktop while observables were smooth even on the mobile.

Interesting discussion! You make references to database tech so what I describe is known to you but I'd just add some obvious thing in case it isn't for someone:

If something is mutable in real life, such as a child's height, then each measurement (sample) is timestamped, and it'll not lose its validity for this timestamp. This is called valid time. Beyond this, the wall time of the entry may be recorded as well, called the transaction time in bitemporal terms. It is possible that the reading was erroneous or entry was fat-fingered, so a new tuple is created with the (now hopefully) correct weight with the same valid date but a new transaction date. So, again, a new, immutable, persistent entry was made.

Databases such as DB2 implement features of SQL:2011 such as temporal tables. They allow the storage of such immutable entries and provide the collapsed (temporally resolved) views. Also, PostgreSQL uses the implementation technique called MVCC which purposefully does the thing you seek to avoid: via Multiversion Concurrency Control, preserve the snapshotted relations as they were at the beginning of a transaction, to ensure Isolation of ACID in the face of concurrency.

To me it seems that it's perfectly okay and desirable for observables to stream immutable pieces of data, i.e. values, while not engaging in an overly early binding to an optimization strategy that sacrifices the temporal aspect at the earliest moment - especially in a tool that claims to be a version of Functional Reactive Programming in its one-sentence summary.

It is possible to have reducers (scan) that collapse a primary, immutable measurement stream into required temporal resolutions. For example, one such resolution may do away with both valid time and transaction time, just emitting changes, and maybe some 'last measured' or 'last updated' time. Some other reductions may yield analytics, for example, to visualize how often certain values change, or how often values are revised due to reading or entry error. Also, even the most elementary reductions such as key=child may carry with them the relevant timestamps.

Deeper analytics may apply some applicable smoothing of the data over time, e.g. a child's weight might be smoothed via LOESS or just cubic splines. Also, the velocity of weight gain may be modeled as the differentiation of the weight over time. We're walking into proper continuous time FRP: this differentiation might be performed via some proper numerical technique e.g. using a five point stencil with backward finite difference.

I used the child weight as an example, but it's quite similar if one implements game-like user interactions where timing matters a lot, or consistent views over financial data streams on a trading platform.

All in all, I don't immediately see how mutability would add utility in this context, but I'm not familiar with MobX constraints which is why I made more general comments which are not new to you but might be interesting to someone else.