Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
developit
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
10 ms
·
31.
▲
by
developit
9y ago
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
32.
▲
by
developit
9y ago
You can use the PWA anywhere, it works very well.
33.
▲
by
developit
10y ago
That would make collaboration much much more difficult :)
34.
▲
by
developit
10y ago
I love this as a job perk. Get paid while giving back.
35.
▲
Show HN: Fetch polyfill in 500 bytes
(github.com)
23 points
by
developit
10y ago
|
0 comments
36.
▲
by
developit
10y ago
Just size and a few really minor API nitpicks. If you're writing for Node, just use the built-in one.
37.
▲
Mitt: 200 byte functional event emitter / pubsub
(github.com)
14 points
by
developit
10y ago
|
2 comments
38.
▲
by
developit
10y ago
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, hah
39.
▲
by
developit
10y ago
If you're loading libraries individually off a shared CDN, performance must not be much of a concern :P
40.
▲
by
developit
10y ago
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 no
41.
▲
by
developit
10y ago
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.
42.
▲
by
developit
10y ago
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 th
43.
▲
by
developit
10y ago
gah this makes me want a sonos
44.
▲
by
developit
10y ago
You should probably look at the test before making firm opinions on the matter. Do you even know what is failing?
45.
▲
by
developit
10y ago
That is untrue. There are currently two small test failures in IE on master, hence the graph. The library supports IE9+.
46.
▲
by
developit
10y ago
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&
47.
▲
by
developit
10y ago
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
48.
▲
by
developit
10y ago
Broken how?
49.
▲
by
developit
10y ago
Seems a little outdated to stick with ES5, particularly in the examples.
50.
▲
by
developit
11y ago
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 complet
51.
▲
by
developit
11y ago
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.
52.
▲
by
developit
11y ago
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.
53.
▲
by
developit
11y ago
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, si
54.
▲
by
developit
11y ago
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'
55.
▲
by
developit
11y ago
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.
56.
▲
by
developit
11y ago
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
57.
▲
by
developit
11y ago
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.
58.
▲
by
developit
11y ago
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.
59.
▲
by
developit
11y ago
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
60.
▲
by
developit
11y ago
If you listen closely you can hear the sound of all bower-dependent builds on earth failing in synchrony
More ›