package.json `main` doesn't point to a commonjs module

[marvinhagemeister]

It's my first run at trying out ivi with node and since node doesn't support import/export statements it throws an exception:

/myproject/node_modules/ivi/dist/js/ivi.js:7
export { DEV_MODE, setDevModeFlags, printError, printWarn } from "./dev_mode/dev_mode";
^^^^^^
SyntaxError: Unexpected token export

Seeing that both webpack and rollup look for the key module first before looking at main in package.json. We could easily get the best of both worlds.

[localvoid]

Yes, I've used to publish several package versions, but also according to this convention module packages should be transpiled to es5 with es6 modules. Angular community is now adopting a new convention with es2015 packages for es6 code with es6 modules, but rollup-resolver doesn't support it.

Also, it is better to wait until I publish 0.8.0 in a couple of days, I am completely changed public API to make sure that it is possible to implement efficient server-side rendering. And right now it can easily compete with string-based template renderers, especially on Node v9-canary with TurboFan engine.

[leeoniya]

I am completely changed public API to make sure that it is possible to implement efficient server-side rendering

i've been meaning to do the same for a while, too. is your impl also basically this [1] or something crazier?

[1] https://github.com/leeoniya/domvm/issues/158

[localvoid]

Yes, specialized vnode factories like this. Also, blueprint optimization that I've described in this article

Marko benchmarks on Node v9-canary:

search-results:
ivi (0.8.0) x 6,365 ops/sec ±0.79% (93 runs sampled)
marko (4.4.16) x 3,543 ops/sec ±1.48% (85 runs sampled)
react (15.6.1) x 88 ops/sec ±2.67% (71 runs sampled)

color-picker:
ivi (0.8.0) x 21,352 ops/sec ±0.74% (92 runs sampled)
marko (4.4.16) x 8,153 ops/sec ±0.99% (88 runs sampled)
react (15.6.1) x 560 ops/sec ±2.71% (79 runs sampled)

[leeoniya]

nice. comparing against React is basically a sad joke. just a normal vtree build and recursive dump in domvm is already 54x faster with 0 optimizations (200 stateful components, 2000 nodes):

https://github.com/leeoniya/domvm/tree/3.x-dev/demos/bench/ssr

[localvoid]

I just wanted to beat marko in their own benchmarks :)

"Compared to solutions based on JSX that exclusively do virtual DOM rendering, Marko has a huge advantage for server-side rendering." Why is Marko Fast

And simple recursive dump won't be able to compete in their benchmarks.

[leeoniya]

And simple recursive dump won't be able to compete in their benchmarks.

right, hence the recursive string appender which should be much faster than what domvm does now (2x+), it's highly unlikely that it'll get anywhere close to Marko or ivi. i'm definitely not as motivated as you to prove everyone wrong :D

even 1,200+ full page renders /sec is far more traffic than any site i've had to work on. the db/disk would become a bottleneck long before the rendering pipeline. the fact that the React crowd somehow manages to be okay with maxing out at 30/sec is pretty telling of what numbers are sufficient for the 99%.

[marvinhagemeister]

@localvoid Knowing that node >= 7.x has full support for es6 (except import/export) I'm not sure if adopting angular's way is the right one. They do have to be cautious with backwards compatibility and have to support node 6.

Thing is that the current bundling strategy prevents building an ecosystem around ivi. I'm currently writing a babel-plugin that transforms jsx to direct VNodes (far from finished). Basically an experiment to compile as much ahead of time as possible.

// input
function Foo() {
  return <div>foo</div>;
}

// output
function Foo() {
  return new VNode(...);
}

I'm currently blocked by this issue because I can't use anything from ivi directly. At this point I can:

• transpile ivi and ship the transpiled code as part of my plugin (current workaround)
• maintain a fork (obviously a really bad idea)
• Fix upstream (best case)

I really hope we can go with the last option. With Happy to send a PR if we can agree on it.

[localvoid]

Added commonjs modules for all packages. I can also add flattened UMD bundles, so it will be possible to use them directly from unpkg cdn.

[leeoniya]

turns out my NODE_ENV wasnt getting set properly (Win vs Linux foo 😠) the actual perf vs React is 14.2x. updated numbers are all from a slower machine [1]. sorry, had to correct myself. will shut up and go away now!

[1] https://github.com/leeoniya/domvm/tree/3.x-dev/demos/bench/ssr

[marvinhagemeister]

@localvoid Awesome, that was quick! Thank you so much 🎉 Building umd bundles as well sounds great for beginners who usually are a bit intimidated with a build chain. Would be really great for quick jsfiddles or codepens, too 👍