-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
package.json main
doesn't point to a commonjs module
#1
Comments
Yes, I've used to publish several package versions, but also according to this convention 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. |
i've been meaning to do the same for a while, too. is your impl also basically this [1] or something crazier? [1] domvm/domvm#158 |
Yes, specialized vnode factories like this. Also, blueprint optimization that I've described in this article Marko benchmarks on Node v9-canary:
|
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 |
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. |
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%. |
@localvoid Knowing that Thing is that the current bundling strategy prevents building an ecosystem around // 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
I really hope we can go with the last option. With Happy to send a PR if we can agree on it. |
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. |
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 |
@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 👍 |
It's my first run at trying out ivi with node and since node doesn't support
import/export
statements it throws an exception:Seeing that both webpack and rollup look for the key
module
first before looking atmain
inpackage.json
. We could easily get the best of both worlds.The text was updated successfully, but these errors were encountered: