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.
> 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.
> 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 React-like library.
2: I've heard more than a few people mention Preact.
3: I discover something really awesome about it that will save me lots of time.
Apart from those events, I'll simply ignore it and not worry if I made the wrong decision. You have the power to ignore me too libraries.
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 equal consideration and using new frameworks just because they're what's "in".
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.
> 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.
Unless you're one of the minority of folks who read all the new trends and follow all the new releases, you won't know not to include some or all of the Me Toos in your AOA.
Most anyone who falls into the less-than-expert experience level included, which covers a ton of folks having to waste far too much time evaluating all these different libraries (and sometimes or often making bad choices as a result).
What's the technical debt and wasted time in the industry due to "I've got an idea" library glut? More than a bit, I'd wager.
Jquery-UI in particular had a lot of competitors, and it just overran all of them before itself dying an ignoble death of stagnation while CSS improved to the point that most of what it offered could be done simply in another way.
I would actually not consider jQuery to be innovative as much as it was a refinement/improvement of existing libraries such as Prototype and Dojo. I think jQuery is great so this isn't a knock against it, but rather just saying that sometimes one thing comes out that is revolutionary but then something else that is an improvement/iteration on that smooths out the rough edges and becomes "the one framework to rule them all" (for a few years, at least).
jQuery's api seemed innovative and quite different than the other libraries I used at the time.
- css selectors to get at nodes. Very dom-focused, but without messing w/ prototypes like _Prototype_ did
- almost every function in the api acted on both single nodes and collection of nodes. It seems like it started the 'chaining' trend.
- no complicated class/namespace hierarchy to learn. Every function was on $ or $.fn. `$('.foo').hide('slow')` vs the equivalent in Prototype involved instantiating an Animation object and passing in the dom node, as I recall.
- cared about file size and not clobbering other globals.
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.
>> 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?
“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.
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.
This isn't a customer experience, there are no corporate overlords trying to maximize profit from FOSS.
FOSS projects exist because people want to make them. If someone feels the need to contribute their own time, FOR FREE, in an attempt to improve on something, there is no reason to put them down.
If the project is not useful for anyone it will just die away. It may, however, contribute something great. FOSS developers shouldn't give a damn about your customer experience with the language. They should care about contributing to the ecosystem in whatever way they feel they can.
Some projects turn out better than others, and some innovate in different ways. This one is attempting to innovate by recreating react with a different footprint. Don't use it if you don't like the idea, but don't discourage people from creating because you don't have the same values as them.
I didn't know React was born by taking another library and removing all the polish and most features from it and then publishing it with almost the same name.
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.
One example of a library that has started out this way is lodash, and I think most now consider it superior to the original underscore library. So starting an effort like this sometimes has great results.
Of course, anybody considering using Preact at this stage should already be intimately familiar with React, and it shouldn't factor into a "Backbone or React or Angular or Ember" type decision.
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".
I wished React was more modular; I will never use propTypes (using typescript), server side rendering or target older browsers with it so I'm probably paying for > half the size of React without needing it. Every detail count.
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
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?
You're missing the point he's making. Preact is leaner than react. FF was leaner than mozilla.
React isn't slow (yet?), but it's not hitting any universal limits, there's always scope for leaner, smaller and faster software (yes it is, see benchmark).
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.
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 on individually if you're not looking for a kitchen sink solution.
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.
While I feel like I'm close enough to tame the React ecosystem (and like it!), I honestly agree. Personally I do prefer opinionated. Luckily Ember exists in the JS world.
Ember is awesome, it doesn't seem to get much love on HNews though. Which is a shame because its really really good - I tried react and spent 2 days messing with various starter packs, trying to get webpack configured and not getting anywhere. Ember took me half an hour to get started.
Because Ember devs already found the best tool years ago and they are super productive. The community is huge and super active but they definitely totally ignore this "fatigue" bullshit... you know, if you found your love of your life, you don't go any more in the dance club to chase other boys/girls... ;)
Ember 2 was released middle of last year and the transition was super smooth. Ember's update pipeline is strict and the backward compatibility is serious. Big startups and corporates are switching to Ember, because they want results... Luckily, we can say, at the moment Ember.js is at least 1 year, but more likely 2 years ahead of other js libraries and frameworks. The framework really matured, the best bet nowadays if someone plan to build larger frontend application.
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 monolithic blob in the first place that's not going to be possible.
My main issue with modularity in JavaScript is the lack of strict typing, because you won't know if your interface fits correctly until runtime - which is why I've been looking into TypeScript and Elm recently.
Hiya! author here. I have used Mercury and Mithril, both are great. I personally think there is a use-case for both modular and batteries-included libraries. There's an open issue for modularizing preact in the tracker that'll be addressed shortly if that helps.
@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.
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.
There is absolutely nothing stopping people aggregating modular pieces into boilerplates that work well. Developer productivity isn't some entity manifest from a singular repetitive workflow. That sounds to me like an appeal to create dumb cogs of critical thinkers.
Can you justify why 'monolithic frameworks' is the right direction?
You could take 10 seconds and write 1-line modules to abstract your specific imports - "import Component from 'mycomponent'". This is not a valid argument in favor of modularity or small modules (and I love small modules).
It started as a CodePen. Thankfully, someone switched the build to use Rollup, which makes it very easy to move things around. Modular structure (in terms of files) will be part of the 3.0 major bump.
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?
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.
Yep; It's also in a completely different category, on its own. incremental-dom's API is very imperative, so completely different from React & others design goal.
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.
It's always interesting to see a fresh take on something already in use, especially when the focus is on optimization.
However, I completely disagree that Preact is a "React alternative." React is not simply a bunch of code. It's an entire ecosystem with a large community supported by a well-funded entity. A lot of these new libraries and/or frameworks popping up seemingly every other week and claiming to be an alternative to X are just not up to par with the competition and/or the expectations of developers.
Whenever I see something new on the radar, I look at the documentation and commit history. Anything unproven without good documentation, examples, unit tests and/or performance tests is just ignored. If I really like the concept, I'll bookmark it and check on it periodically.
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?
PropTypes are supported out of the box in preact-compat. You could also use them via a preact vnode hook and the "proptypes" module (npm.im/proptypes), which is just pulled from React's codebase. Synthetic events I'm very much open to feedback on - I tend to fire actual DOM events in my Karma tests, but it seems that less common.
This is extremely interesting to me and I would love to hear why. I skipped synthetic events because I didn't feel they were necessary, but I would appreciate additional insight.
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...
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.
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.
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.
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.
Not in the class declaration, though. Why force the programmer to go through the prototype, when ES6 provides such a "convenient" abstraction around it?
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).
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.
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.
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.
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 lifecycle? Cheers.
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.
There's not going to be any interesting features around the type system.
There's no change in the type system. Javascript is still a prototype based language.
There's no real value to a class system in a dynamic language, beyond synthetic sugar. Arguable prototypes are better since you don't get to question "if everything is an object, and classes are objects then what class is a class of?"
With ES7 decorators, you can put a mixin into a class... which gives you class sugar + traits, so essentially multiple inheritance without the downsides of it.
RiotJS couldn't keep it to the original size of about 3 KB, it's about 9 KB now. They market it as a "React-like", but it appears that this one is way more "React-like" than RiotJS ever was.
I started using Snabbdom, which is also tiny, but has a nice module/hook API: https://github.com/paldepind/snabbdom (plus 'style' module supports transitions/animations).
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).
Just take a look, how many libraries are written in ES6, clearly not much. So dead code Elimination only works if you have ES6 libs and that will take some time.
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).
A good one, too. The last startup I worked for was one of their first customers. You fire off events, they machine learn normal behaviour for your customers and feed the intel to your customer success team so you can prevent churn and identify your high-performing customers.
Yeah... causing this confusion is one of my more regrettable mistakes of the year. Honestly if some amazing name came along I would not be entirely opposed to changing it.
Interesting. In terms of "React alternatives that are tiny", I have a really big soft spot for domChanger[0]. Really cute syntax, and it works pretty well -- I built most of a TodoMVC implementation with it and Hoverboard[1] (a tiny Flux implementation). I also completed a partial "Flux Challenge" implementation with that same combo [2].
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.
The value proposition of Preact makes no sense to me:
> Preact is an attempt to recreate the core value proposition of React (or similar libraries like Mithril) using as little code as possible, with first-class support for ES2015.
I understand building a faster React, an easier to use React (forms are a nightmare), but a smaller React?
We are talking about saving on the order of 30kb. This doesn't even matter on mobile. Can anyone give me a compelling use case?
>I understand building a faster React, an easier to use React (forms are a nightmare), but a smaller React? We are talking about saving on the order of 30kb. This doesn't even matter on mobile. Can anyone give me a compelling use case?
Less code can also mean its easier to understand and has pruned the legacy/redundant parts (being ES2015 only).
And being able to read the whole code of your framework in one sitting, and understand it, is great.
Besides, it's not like "as little code as possible" is their ONLY goal. They're not merely building a drop-in React replacement with less code. The reference to "Mithril" looks like they'll also investigate their own APIs and ways of hooking components etc, which will be similar in concept but different than React's exact APIs -- they already dropped the non-stateless components APIs.
[addition] Regarding the "order of 30kb savings". Here's an excerpt from their site: "The React-based demo was 1.8mb of JavaScript. This demo, using exactly the same code and with the same functionality, is 60kb.".
less code !== faster code. I wouldn't even try this without seeing some impressive performance benchmarks. Giving up the support of the entire react team and community in exchange for a small framework that may or may not be faster is a huge ask.
In the second benchmark, Preact is only faster in around half of the tests. However, this benchmark only tests complete top-down re-renders and intentionally triggers synchronous rendering in Preact. In a normal app composed of Components, Preact batches state changes which improves performance considerably.
All libraries in uibench have batching, and batching doesn't improve performance, it just prevents from doing unnecessary work during one frame. It is pointless to test performance of different state changes with enabled batching.
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 ( https://wdrl.info/archive/121 ) and never seeing your code amount to anything but a series of band aid and kludges.
> 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.
We have so many choices in the javascript ecosystem that it's pretty impossible to make a meaningful choice.
But, it's very possible to lose time trying to figure out what you "should" choose or even what your choices might be.
And since that's what the parent is bemoaning, your distinction is pretty useless.
Note: If you want to use react then the correct choice is react + redux + webpack. If you want to validate a startup idea, then the correct choice is jquery :)
Silly downvoters: they are responding to your tone rather than the content of your post.
Anyway, for sure there is a tonne of cruft and confusion when starting a new js project(SPA app) nowadays. Esp if you want to use react: it's one of the blessings/curse of using a library vs a framework.
If, however, you stop looking for the "right" way to do things by reading blog posts etc,and just take the easiest path with react, then redux and webpack will take you far enough.
The web is the platform that works across all devices. Sure an app is great when you already use that site, but before they're invested, are people really gonna download an app?
Not to mention that you're heavily reliant on Apple and Google for your framework. With the web, you can use whatever you like, you can even roll your own if you want.
Sure there are a lot of JavaScript libraries, but how else will ideas evolve?
It's still best practice for most normal websites that are mostly static content with a bit of jquery and Ajax sprinkled on top.
But for sites that are more like applications people are thinking about the components that make up those applications. These components are self contained and reused so it makes sense to have everything in the same small file.
I am just sitting here, watching elm organically growing, while people creating "new" react-flux-redux-ember-angular-dojo-backbone frameworks every day.
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.