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

51–60 of 142 posts

Re: Preact, a fast 3k React alternative

#51

Post by sergiotapia »

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.

@Cartwright2: Meteor is heading in that direction with version 1.3. Cohesive toolchain that integrates the best from the Javascript world, that is modular if you want, but ultimately a fantastic developer UX designed for happiness and productivity.

Everything will just work with defaults. Not like this travesty: https://github.com/kriasoft/react-starter-kit

Re: Preact, a fast 3k React alternative

#52

Post by mikewhy »

warfangle wrote: post #42
dceddia wrote: post #4

Earlier quoted context omitted.

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.

FYI, react.min.js does do exactly what browserify + envify would do.[1]

[1]: https://github.com/facebook/react/blob/401e6f10587b09d4e7257...

Re: Preact, a fast 3k React alternative

#53

Post by terrortrain »

Cartwright2 wrote: post #47

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.

Re: Preact, a fast 3k React alternative

#54

Post by leeoniya »

ufo wrote: post #37
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 recently found out about incremental-dom[1], a very small library that just does the "dom updating" algorithm. Its very low level and does not rely on keeping around a "virtual dom tree" so its supposedly very interoperable. Does anyone here have any experience with it? [1] http://google.github.io/incremental-dom/

incremental dom is extremely low level, so low that it's basically DOM assembly. it is not practical and is actually not that fast. many other vdom libs are both more useable and faster.

check out vidom, kivi, citojs, domvm (mine), etc...

domvm is actually one level above pure vdom libs and a level below frameworks. it offers a very fast, stateful and reusable view layer over a vdom diffing engine. it was written to solve some architectural disagreements and speed issues i had with using Mithril MVC for several projects.

Re: Preact, a fast 3k React alternative

#55

Post by jallmann »

Touche wrote: post #46
jallmann wrote: post #44

Earlier quoted context omitted.

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.

Not in the class declaration, though. Why force the programmer to go through the prototype, when ES6 provides such a "convenient" abstraction around it?

Re: Preact, a fast 3k React alternative

#56

Post by Cartwright2 »

terrortrain wrote: post #53
Cartwright2 wrote: post #47

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.

> People should always create and attempt improve upon whats out there. Don't try to stifle innovation...

I agree completely and my argument is that a lot of the Javascript libraries being pushed around over the past three to four years are neither creative nor improvements over what already exists. React is innovative. Redux is (arguably) innovative. jQuery was innovative. Many other libraries have been innovative. I'm arguing against the hundreds upon hundreds of "me too" libraries that make it so much harder to find the truly innovative stuff. These libraries do nothing but add to decision fatigue. Developers have to make decisions, sure, but we need to have limits too.

Re: Preact, a fast 3k React alternative

#57

Post by pacomerh »

terrortrain wrote: post #53
Cartwright2 wrote: post #47

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.

I'm supporting this mentality. You should always be looking for ways to make existing things better. This is exactly how React was born damn it.

Re: Preact, a fast 3k React alternative

#59

Post by andrewclunn »

Cartwright2 wrote: post #47

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…

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

Re: Preact, a fast 3k React alternative

#60

Post by at-fates-hands »

terrortrain wrote: post #53
Cartwright2 wrote: post #47

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.

>> Nope. People should always create and attempt improve upon whats out there.

Unless like he states, it causes decision fatigue. What's easier? Looking through a small group of well documented and supported frameworks OR trying to a find a decent framework among hundreds of frameworks; many of which, I might add, are either poorly documented or have inherit issues you won't discover until you're already too deep in your project to change.

It's interesting to note that in virtually every industry, they realize that giving the customer too many choices leads to fewer sales, less success and leaves them paralyzed and unable to make a decision. Yet, in software development, we firmly believe the exact opposite is true? That somehow giving developers more and more choices is somehow better?

Some more support for what I was saying:

https://www.gsb.stanford.edu/insights/research-too-many-choi...

“People fail to realize that relatively rigid structures can often simplify goal pursuit by removing the need to make choices, especially when people are already well into the process” she says.

http://www.nytimes.com/2010/02/27/your-money/27shortcuts.htm...

That study “raised the hypothesis that the presence of choice might be appealing as a theory,” Professor Iyengar said last year, “but in reality, people might find more and more choice to actually be debilitating.”

Research also shows that an excess of choices often leads us to be less, not more, satisfied once we actually decide. There’s often that nagging feeling we could have done better.

Post reply on HN