developit

This is not true, since Preact only implements the same software interface. Its internals are fundamentally different and not a derivative work.

Software interfaces cannot be patented - this has been upheld in every court, most recently in Google V Oracle.

You can use the PWA anywhere, it works very well.

That would make collaboration much much more difficult :)

I love this as a job perk. Get paid while giving back.

Just size and a few really minor API nitpicks. If you're writing for Node, just use the built-in one.

Yup, though the Rax benchmarks are especially bad. Calling a function with unchanging arguments in a loop with a constant number of iterations is going to trigger about the least real-world performance characteristics you could ask for, haha. I'm happy to see more people getting into the VDOM space, but it sucks to have to explain all the pitfalls every time a new broken benchmark comes out.

If you're loading libraries individually off a shared CDN, performance must not be much of a concern :P

FWIW, there is actually no code in React to normalize touch events between browsers. For touch events react and preact are basically the same (aside from React creating a lot of pooled objects for their synthetic event system, and preact not using delegation).

So far, for the use-cases I can think of, it's probably not worth it. Serialization and thread overhead outweigh any benefit. There are definitely better use-cases for workers than VDOM.

The theory is that if the diff were sufficiently expensive on its own (it's generally not), that cost is offloaded. There may be gains to be made by moving most of the application code out of the UI thread (less memory usage in that thread, etc).

In this demo, all the UI thread is doing is receiving batches of small instructions to update the DOM. Stuff like "change the text content of element #12" (all elements get assigned an ID).

That said, this is just an experiment. I wanted to get a real sense of whether threading was something we should care about for DOM manipulation.

gah this makes me want a sonos

You should probably look at the test before making firm opinions on the matter. Do you even know what is failing?

That is untrue. There are currently two small test failures in IE on master, hence the graph. The library supports IE9+.

Agreed. Someone submitted this before I got around to writing that post, heh. Synopsis: fake DOM in the worker w/ MutationObserver that sends batched changes up to the UI thread. Event delegation to get things back into the worker. It's actually relatively straightforward, demo code is a mess though.

I think it's important people understand this. The last two points are precisely the reason String refs got moved from Preact's core into preact-compat.

Also, for the common-case usage of string refs, you can just use a helper to insert things into `this.refs`:

https://gist.github.com/developit/63e7a81a507c368f7fc0898076...

Broken how?

Seems a little outdated to stick with ES5, particularly in the examples.

https://github.com/developit/preact-perf https://localvoid.github.io/uibench/

In the second benchmark, Preact is only faster in around half of the tests. However, this benchmark only tests complete top-down re-renders and intentionally triggers synchronous rendering in Preact. In a normal app composed of Components, Preact batches state changes which improves performance considerably.

Yeah... causing this confusion is one of my more regrettable mistakes of the year. Honestly if some amazing name came along I would not be entirely opposed to changing it.

Yup. I've successfully added contexts to Preact, but I still am not 100% sold on the value. Thankfully, simply supporting them doesn't add much bloat.

Not to pile on here, but I try to use pure functions instead of Components as often as I can. The class keyword is sugar, sure, but like others have said - that ship has sailed. Personally, I just like that it's a language feature, since Components are the only time I ever use the class keyword my brain treats them as a 1:1 mapping. Perhaps it has something to do with both Classes and Components having a defined lifecycle? Cheers.

PropTypes are supported out of the box in preact-compat. You could also use them via a preact vnode hook and the "proptypes" module (npm.im/proptypes), which is just pulled from React's codebase. Synthetic events I'm very much open to feedback on - I tend to fire actual DOM events in my Karma tests, but it seems that less common.

This is extremely interesting to me and I would love to hear why. I skipped synthetic events because I didn't feel they were necessary, but I would appreciate additional insight.

You could take 10 seconds and write 1-line modules to abstract your specific imports - "import Component from 'mycomponent'". This is not a valid argument in favor of modularity or small modules (and I love small modules).

In my case, I wanted to take advantage of React-style components, but needed to use them in a massive (MM users) 10-year old website built on jQuery and Backbone, backed by PHP. Since there is no room for overhead, Preact fits very nicely.

It started as a CodePen. Thankfully, someone switched the build to use Rollup, which makes it very easy to move things around. Modular structure (in terms of files) will be part of the 3.0 major bump.

Hiya! author here. I have used Mercury and Mithril, both are great. I personally think there is a use-case for both modular and batteries-included libraries. There's an open issue for modularizing preact in the tracker that'll be addressed shortly if that helps.

If you listen closely you can hear the sound of all bower-dependent builds on earth failing in synchrony