Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Preact, a fast 3k React alternative

developit.github.io

Post reply on HN
Print view View original

21–30 of 142 posts

Re: Preact, a fast 3k React alternative

#21

Post by jallmann »

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? In that case, why not wait until ES7 is fully baked to build interesting features around the type system, instead of making yet another Java derivative...

Re: Preact, a fast 3k React alternative

#22

Post by merb »

udp wrote: post #15

We don't need smaller frameworks, we need more modular frameworks. If the framework is modular you can take what you need, and replace the parts you don't like. I'm using mercury [0] in my current frontend project for this purpose. Most of the features of React, none of the commitment. Every single component is interchangeable; the core repository is simply an index.js requiring other modules, which can be depended o…

then you should look at this library. Currently I'm skeptical about every js library, however this library makes a lot of things good.

Especially by using ES6. Also these guys made some cool addon libraries that are as small as the core library.

The only thing I dislike is that the core library is a single source file. Why do people create source files with < 1000 lines..

Re: Preact, a fast 3k React alternative

#23

Post by pkozlowski_os »

LaurensBER wrote: post #5
rpedela wrote: post #2

How big is React gzipped? How much are you saving with this library?

Perhaps even more important, does library size still matter once dead-code elimination is an option in Webpack2? See: https://twitter.com/dan_abramov/status/656970508005736448

If you test currently available dead-code elimination tools for JS you will discover that there are tricks that those tools can't play, most important one being eliminating unused methods on object / classes.

AFAIK Webpack2 is using Rollup under the hood. While rollup is great and can build smaller outputs (biggest win seems to be elimination of the module system overhead) it can't perform miracles.

In short: size still matters, even with dead-code elimination tools (at least as they are today).

Re: Preact, a fast 3k React alternative

#25

Post by nilliams »

jallmann wrote: post #21

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…

Well for one 'class Foo extends Bar' will work without any further code to make inheritance work in the way you'd expect, including use of super() etc. Whereas your second example is using non-trivial framework code, that some framework author has to write. See Backbone's extend() for a clear example of what is required [0]. That's work that every framework author is potentially going to implement differently, needlessly.

And the fact that almost every major framework has implemented something similar themselves is proof enough (for me at least) that the ES6 sugar is valuable. It has nothing to do with Java, it's simply a useful pattern that everybody was already using.

[0] http://backbonejs.org/docs/backbone.html#section-247

Re: Preact, a fast 3k React alternative

#26

Post by Ronsenshi »

losvedir wrote: post #8

Where do the savings come from? I can't imagine that React.createClass() is all that much code. I'm guessing a lot of space saving comes from not doing PropTypes (which I find immensely useful) and not having a synthetic event system (meaning you can't test with TestUtils.Simulate.click()). What else is missing I wonder?

Lack of synthetic events is a huge one for me.

Re: Preact, a fast 3k React alternative

#27

Post by peterhunt »

losvedir wrote: post #8

Where do the savings come from? I can't imagine that React.createClass() is all that much code. I'm guessing a lot of space saving comes from not doing PropTypes (which I find immensely useful) and not having a synthetic event system (meaning you can't test with TestUtils.Simulate.click()). What else is missing I wonder?

Also property/attribute normalization.

Preact: https://github.com/developit/preact/blob/master/src/preact.j...

React: https://github.com/facebook/react/blob/3b96650e39ddda5ba4924...

Re: Preact, a fast 3k React alternative

#28

Post by jallmann »

nilliams wrote: post #25
jallmann wrote: post #21

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…

Well for one 'class Foo extends Bar' will work without any further code to make inheritance work in the way you'd expect, including use of super() etc. Whereas your second example is using non-trivial framework code, that some framework author has to write. See Backbone's extend() for a clear example of what is required [0]. That's work that every framework author is potentially going to implement differently, needle…

The question is whether that ~15 lines of code, written once, is worth the substantial increase in the surface area of the language, especially when overlapping so much with the existing prototypal inheritance mechanism. The choice to use Java/C++-style inheritance is a design pattern that doesn't necessarily reflect the only (or even the best) way to accomplish things.

Re: Preact, a fast 3k React alternative

#29

Post by qaq »

jallmann wrote: post #28
nilliams wrote: post #25

Earlier quoted context omitted.

Well for one 'class Foo extends Bar' will work without any further code to make inheritance work in the way you'd expect, including use of super() etc. Whereas your second example is using non-trivial framework code, that some framework author has to write. See Backbone's extend() for a clear example of what is required [0]. That's work that every framework author is potentially going to implement differently, needle…

The question is whether that ~15 lines of code, written once, is worth the substantial increase in the surface area of the language, especially when overlapping so much with the existing prototypal inheritance mechanism. The choice to use Java/C++-style inheritance is a design pattern that doesn't necessarily reflect the only (or even the best) way to accomplish things.

It's to a degree for people who are not primarily JS developers and often have no clue about prototypical inheritance. It also to a good degree reflects how V8 or some other engine actually treating your code under the hood.

Re: Preact, a fast 3k React alternative

#30

Post by dang »

harryf wrote: post #12

Oh another JavaScript framework. Of course the world needs that. If I was recommending a development path to a young developer I would have to say choose the "dark side" and become an app developer and let Apple / Google feed you your framework. Don't waste your time on the web - you'll waste your life learning this weeks flavor of the month framework while lacking core understanding of the underlying technology ( ht…

> Oh another JavaScript framework. Of course the world needs that.

We're trying to avoid snarky dismissals here, especially in response to new work. Substantive criticism is fine, so this comment would be better with just the second paragraph.

Post reply on HN