Live data from Hacker News

Preact, a fast 3k React alternative

developit.github.io

101–110 of 142 posts

Re: Preact, a fast 3k React alternative

#101
post #38
post #35

Earlier quoted context omitted.

Mercury fans always say this but I'm never seen anyone swap out random libraries it uses, like dom-delegator. Stuff is still made to be used together, you could swap out dom-delegator if your version had the exact same API, but then what would be the point.

When I ported my frontend to TypeScript I swapped out the whole observ* suite for my own typed observables. Sure, some of the components are too specific to replace trivially, but then those most likely aren't the ones you're interested in replacing. Decomposing your code into modules is step one. Making the interface between your modules generic enough to easily replace is the next problem, but if your code is a mon…

Or you could just have written a .ts.d file?

Re: Preact, a fast 3k React alternative

#102

Off-topic, but am I the only one who thinks that classes are the most puzzling feature of ES6? How is writing "class Blah extends Component { ... }" any better than "Blah = Preact.createComponent({ ... })", except to save a few keystrokes? ES6 is full of syntactic sugar to improve readability, but classes substantially increase the "surface area" of the language for... what benefit? Static analysis and tooling, maybe…

I could not disagree more. To me the readability benefit of classes, "extends" and "static" that work intuitively, "constructor", "super", etc. is immense, especially when you pair with something like Facebook Flow that let you declare the members with types. I consider it one of ES6's most compelling features. No more writing out "MyClass.prototype" just to declare basic classes with methods.

Absolutely -- having a typed object structure helps with tooling, as I mentioned. There are a lot of nice features that can be built around a solid type system to increase expressivity and improve safety. JS classes, as implemented, are an uninspiring facsimile of OO APIs, adding a lot of new syntax while papering over just enough semantic differences that it feels like a bit like an admission of defeat for the old paradigm.

I don't write nearly enough JS to say there is unequivocally a better way to write programs, but it's a bit disappointing that no one has figured out more advantageous ways to leverage the nature of the language without, IMO, leaning so much into cultural "learned behavior" from other OO languages.

Re: Preact, a fast 3k React alternative

#103

Earlier quoted context omitted.

Last time I checked you couldn't use contexts yet.

Thats a good thing. Context is not a good feature, and even the developers didn't want to write documentation for it because they didn't want people to use it. https://github.com/facebook/react/issues/580

Then how would something like react-redux work without context?

Re: Preact, a fast 3k React alternative

#104

I'm not sure that we should be doing this. Yes, it stands to reason that if you take framework X, cut out a lot of functionality, remove some of the "ugly" code that addresses edge cases, then you end up with a similar, reduced framework which is smaller in file size. But this is done at the cost of polluting the Javascript framework environment. The biggest problem right now is pollution, we're all drinking from the…

Nope. People should always create and attempt improve upon whats out there. Don't try to stifle innovation for the sake of making decisions simpler. If you don't want to make decisions, don't use libraries, or use an opinionated framework.

Any time anyone posts anything new on here for Javascript, I just want an auto-poster with this: https://xkcd.com/927/

Re: Preact, a fast 3k React alternative

#105

Off-topic, but am I the only one who thinks that classes are the most puzzling feature of ES6? How is writing "class Blah extends Component { ... }" any better than "Blah = Preact.createComponent({ ... })", except to save a few keystrokes? ES6 is full of syntactic sugar to improve readability, but classes substantially increase the "surface area" of the language for... what benefit? Static analysis and tooling, maybe…

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 life…

It's enlightening to hear why people seem to like this feature so much, so thanks for chiming in. While I'm still mystified (probably due to my PL tastes more than anything), I'll stop complaining for today.

Re: Preact, a fast 3k React alternative

#106
post #72

Earlier quoted context omitted.

What if you need something very lean for a specific purpose that React would do well, but it is just too big to justify it. That's ironically an edge case where React fails to deliver and this project fits neatly.

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.

Mithril was too big?

Re: Preact, a fast 3k React alternative

#108

I'm not sure that we should be doing this. Yes, it stands to reason that if you take framework X, cut out a lot of functionality, remove some of the "ugly" code that addresses edge cases, then you end up with a similar, reduced framework which is smaller in file size. But this is done at the cost of polluting the Javascript framework environment. The biggest problem right now is pollution, we're all drinking from the…

I have to disagree. The inherent nature of open source is forking projects just to make some small change that you really want. Sometimes those changes make it back into the original project and improve it. Code diversity is far more important than "developer fatigue".

Re: Preact, a fast 3k React alternative

#109
post #99

Re: fast claim, it turns out it's not that fast: http://localvoid.github.io/uibench/ :(

My results: Preact 2.7.3 took 864920; React 0.14.6 took 435580 There were some benchmarks where Preact was faster, but overall half React's speed.

Preact is using implicit dom recycling, so it heavily breaks use cases like "tree/[*]/render". Just hold mouse over its time and it will display "max" time, it will be much closer to reality.

All other libraries either don't have any form of recycling dom nodes, or it is disabled for this benchmark.

Re: Preact, a fast 3k React alternative

#110

Earlier quoted context omitted.

Except it targets the React API, so the fracturing isn't really an issue.

well there's now 2 copies of the code, so everything is being maintained twice, there are twice as many opportunities for bugs, they have a list of "preact only" extensions (eg preact-router) that are only necessary because there's now another franework

biodiversity is a good thing.
Post reply on HN