I am just sitting here, watching elm organically growing, while people creating "new" react-flux-redux-ember-angular-dojo-backbone frameworks every day.
I meant to troll, sorry.
Preact, a fast 3k React alternative
81–90 of 142 posts
Re: Preact, a fast 3k React alternative
#82We 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.
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.
Re: Preact, a fast 3k React alternative
#83We 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…
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.
Re: Preact, a fast 3k React alternative
#84Earlier 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…
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?
Re: Preact, a fast 3k React alternative
#85We 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..
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.
Re: Preact, a fast 3k React alternative
#86I'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…
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.
Re: Preact, a fast 3k React alternative
#87Earlier 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…
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).
Re: Preact, a fast 3k React alternative
#88Where 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.
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.
Re: Preact, a fast 3k React alternative
#89Where 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.
Re: Preact, a fast 3k React alternative
#90Off-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…
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.