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

41–50 of 142 posts

Re: Preact, a fast 3k React alternative

#41

Post by jlas »

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…

> Don't waste your time on the web

I feel sorry for the young developer

Re: Preact, a fast 3k React alternative

#42

Post by warfangle »

dceddia wrote: post #4
rpedela wrote: post #2

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

Looks like React 0.14.6 is about 38k gzipped: curl --silent --output /dev/null -H "Accept-Encoding: gzip,deflate" --write-out "size_download=%{size_download}\n" https://cdnjs.cloudflare.com/ajax/libs/react/0.14.6/react.mi... >> size_download=39542

That doesn't remove everything behind process.env.NODE_ENV !== 'production' though.

Though, you do need webpack/browserify/etc to take advantage of that.

Re: Preact, a fast 3k React alternative

#43

Post by sergiotapia »

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…

Great in theory, horrible in practice.

How much time did you spend setting up the plumbing for the project? That's key.

Re: Preact, a fast 3k React alternative

#44

Post by jallmann »

Touche wrote: post #36
jallmann wrote: post #28

Earlier quoted context omitted.

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.

ES6 classes do not use Java/C++ style inheritance, they are still the same as writing: function Foo() { } Foo.prototype = Object.create(Parent.prototype); .... It's just sugar, nothing more.

The semantics of JS classes are still different in enough subtle ways: constructors and constructor subclassing, (lack of) object properties, hoisting, etc. That is on top of the new keywords, new function syntax, etc. All that needs to be mapped onto the model of "classical" Javascript in order to completely understand the language. There are enough gotchas there to disqualify JS classes from being simply sugar.

Re: Preact, a fast 3k React alternative

#45

Post by cageface »

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…

I prefer opinionated, integrated frameworks. I can count on the whole stack being well tested and don't have to worry about subtle bugs and versioning issues between components.

The JS community has gone way overboard on factoring everything into a dozen little submodules, IMO.

Re: Preact, a fast 3k React alternative

#46

Post by Touche »

jallmann wrote: post #44
Touche wrote: post #36

Earlier quoted context omitted.

ES6 classes do not use Java/C++ style inheritance, they are still the same as writing: function Foo() { } Foo.prototype = Object.create(Parent.prototype); .... It's just sugar, nothing more.

The semantics of JS classes are still different in enough subtle ways: constructors and constructor subclassing, (lack of) object properties, hoisting, etc. That is on top of the new keywords, new function syntax, etc. All that needs to be mapped onto the model of "classical" Javascript in order to completely understand the language. There are enough gotchas there to disqualify JS classes from being simply sugar.

You can add object properties to a ES6 class's prototype, no?

EDIT: Just tested in Firefox and indeed you can.

Re: Preact, a fast 3k React alternative

#47

Post by Cartwright2 »

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 fire hose of frameworks and someone needs to cut the supply so we can double-down on the good stuff and stop jumping from one framework to the next like a plastic bag caught in a strong breeze.

Preact is now a decision point for any developer who Googles "react alternative" and scans far enough through the search results. This isn't right. This contributes to decision fatigue. It's time to stop churning out new frameworks that are only marginally different from what's already available.

Re: Preact, a fast 3k React alternative

#48

Post by Cartwright2 »

sergiotapia wrote: post #43
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…

Great in theory, horrible in practice. How much time did you spend setting up the plumbing for the project? That's key.

I think, and hope, that the "modularity" of the Javascript ecosystem will lead to extreme decision fatigue, followed by a doubling-down on the best individual modules, aggregation into larger, monolithic frameworks that work well, and finally an increase in developer productivity and standardization of the choices of frameworks. At this point, the Javascript field will no longer be in shambles as it is today.

All it will really take is one person to merge, say, React with a boilerplate-reduxed Flux framework, a REST library, and a handful of other must-haves, under a single, new product name. Let's call it "Rimble". When people realize they can "import { Component, Actions } from Rimble" we'll see a shift towards monolithic frameworks and the ball will start rolling back in the right direction.

Re: Preact, a fast 3k React alternative

#49

Post by leeoniya »

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…

try domvm [1] it's maturing fast, 8k min, isomorphic, has pure js templates, is extremely quick [2] and allows you to write truly reusable imperative/declarative components. disclaimer: mine.

[1] https://github.com/leeoniya/domvm

[2] http://leeoniya.github.io/domvm/test/bench/dbmonster/

Re: Preact, a fast 3k React alternative

#50

Post by djacobs »

Touche wrote: post #36
jallmann wrote: post #28

Earlier quoted context omitted.

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.

ES6 classes do not use Java/C++ style inheritance, they are still the same as writing: function Foo() { } Foo.prototype = Object.create(Parent.prototype); .... It's just sugar, nothing more.

I'm not yet convinced that it's just syntactic sugar. For example, what (generic) code is `super` syntactic sugar for?

Even if it is just syntactic sugar, that syntactic sugar makes it much more approachable for devs who want to use classical inheritance (not that I'd encourage that).

Post reply on HN