Live data from Hacker News

Preact, a fast 3k React alternative

developit.github.io

111–120 of 142 posts

Re: Preact, a fast 3k React alternative

#111
post #91
post #50

Earlier quoted context omitted.

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).

> what (generic) code is `super` syntactic sugar for? super.propertyOnSuper ~= this.__proto__.propertyOnSuper super() in constructor ~= ParentConstructor.call(this) and some tools provide such things like this.super_: https://github.com/isaacs/inherits/blob/3af5a10c6b51f9e99d9f...

Thanks for the response. If the choice is between manually specifying that (type of) code for every kind of object (and likely moving to a #create factory method) or using a native syntax for class declaration, I can see why people would choose the latter.

Re: Preact, a fast 3k React alternative

#112
post #78
post #62

Earlier quoted context omitted.

> These libraries do nothing but add to decision fatigue. Developers have to make decisions, sure, but we need to have limits too. Nonsense. These "me too" libraries add to the decision fatigue only if you're including them in your list of candidate libraries in the first place. Personally speaking, I won't even consider Preact until one of the following events has occurred: 1: I tell myself I really really need a 3k…

I agree with this as well. Just because I've heard of Mithril.js doesn't mean I'm going to now start considering Mithril for my projects. One of these Javascript libraries could end up introducing an innovative idea or have a feature that other libraries don't. It wouldn't make sense to just stop making them because there's a lot of them out there. Javascript fatigue only happens when you start giving all libraries e…

The fatigue doesn't come from giving all libraries equal consideration. It comes from having to decide what's "in" and for how long. Sometimes it takes days of research just to decide if something is popular, let alone whether it's going to last.

Re: Preact, a fast 3k React alternative

#113

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…

A note that using extends Component will cost you the function auto-binding that [p]react.createClass provides. In my specific case, using extends produced code that read more poorly.

Re: Preact, a fast 3k React alternative

#114

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

As people adopt external state containers, like Flux and Redux, it becomes increasingly impractical to bucket brigade chunks of data and callbacks to the leaves of the component tree via props. Some sort of delivery mechanism that doesn't couple in intermediate components is pretty critical to avoid having to maintain an unbounded amount of glue code. Context isn't without its kinks, but it's pretty useful in cutting boilerplate and decoupling components. The one thing I don't buy is that it's somehow worse than props from an architectural perspective (it's often compared to global variables, which makes little sense to me).

Re: Preact, a fast 3k React alternative

#115

Earlier quoted context omitted.

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.

Frameworks aren't life and this isn't diversity anyway. It's React without contexts, refs and proptypes that has fewer developers and significantly less testing. And it's not the only one, because react-lite is React without server-side rendering.

How the hell is feature ripping and repackaging (after removing carefully crafted edge case handling) diversity?

Re: Preact, a fast 3k React alternative

#116

Earlier quoted context omitted.

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…

[deleted]

Re: Preact, a fast 3k React alternative

#117

Earlier quoted context omitted.

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

Freedom of speech

Re: Preact, a fast 3k React alternative

#118

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.

No, such derivative work, is pretty much the opposite of innovation. It is like 'Apple made another color variant of this year's iPhone, awesome, check it out'.

What's worse, they are maybe 10s of them every week, distract the community's focus to improve let alone perfect current system.

Re: Preact, a fast 3k React alternative

#119

Earlier quoted context omitted.

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

So maybe it is time to stop and instead of making of/searching for yet another JS lib just think, should I be doing this on the web in this way at all. This trend to make everything on the web into some kind of application has already thrown out of the window all the good that was done for the web in the past 10-12 years.
Post reply on HN