I enjoyed reading this write-up. Used this technique in the past and have seen similar improvements as they mentioned in this article. [1] This was pre the FCP, LCP, CLS metrics so it considers the onload timings. Would be interesting to know on which percentiles this increase is seen and if this is measured with real user metrics (RUM) or captured by a synthetic tool such as lighthouse or web page test.
There's also a babel script that you can drop into a script tag and will transpile stuff in the browser for you if you want JSX.
Not recommended for large projects in production (but then I'd be using webpack or similar for large vue projects too), but it works pretty well (and surprisingly fast) for quick experiments.
Moving the goalpost. I'm only pointing the fact that it is possible, and saying it is impossible is false.
Personally, I don't find the function-call format that "annoying", and I think it presents some advantages neither JSX nor template strings have, along with some disadvantages (it's more verbose, like you pointed out).
And I think GP was saying even if possible it seems rather irrelevant. You could use react without JSX but most likely you will not because you would be throwing away the good things about react.
Technically you can eat soup using a fork, but you won’t because...
When React was new and compilers/tooling wasn't that good it was pretty common to use it without JSX. JSX is pervasive because the tooling is now first class (and you'll need it if you make a non-trivial app sooner or later...at which point might as well use JSX since its there), but it works perfectly find without. My first couple commercial apps for React didn't use JSX and it was quite usable. There's just a lack of examples on how to do it these days because no one bothers.
The only time when you won't really have access to a tool chain is for quick demos with just an html page and a script tag (if you don't want to pull in babel as a script), but most online tool allow jsx too now anyway.
JSDoc is just an equivalent [1] to Javadoc [2] (and PHPDoc is another one). Those formats just describe what you can do with your comments in code that look like this:
/ * * some documentation * /
The Javadoc tool converts those comments to a collection of clunky HTML sites with documentation [3] that we all know.
What the project linked here does is similar: Just like the Javadoc tool, it converts your comments from code into a well-readable documentation -- but not with clunky HTML but in concise Markdown.
To see an example, just put this sample Java code [4] into the box and convert.
What are reasons to use bower over NPM? I know that bower mainly focusses on front-end libraries (such as jQuery or Bootstrap). But does it offer functionality NPM doesn't have?
Bower installs dependencies in a flat folder structure, whereas NPM nests them. This makes it much easier to use Bower with a client-side module loader.
Bower is also (easily) configurable where bower_components will be, whereas I don't think NPM is as easily.
While I can't speak for the author, one benefit of packaging your app with node-webkit[1]; is that your app is always used inside this container, that bundles a very recent version of Chromium and has a node.js backend with file system access.
Probably is actually, I'd expect there's little need to update the list if said list is not being looked at. On the other hand, it might be fairly costly while the system is being watched as it will fire (and do some check) on every single frame.
requestAnimationFrame may be too frequent in the foreground (could effect performance?), and not necessarily 0 in the background.
That repaint may occur up to 60 times per second for foreground tabs (the exact rate is up to the browser to decide), but may be reduced to a lower rate in background tabs.
[1]: https://techlab.bol.com/en/blog/our-ride-to-peak-season-fron...