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.

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.

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.

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?

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 -

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.

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 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.

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

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.

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.