Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
I created a minimalist library to replace Redux
15 points by stevendesu on Sept 18, 2016 | hide | past | favorite | 5 comments
When I say "replace Redux", I by no means intend to imply that I want to oust it. Redux is awesome, and it's the king of the hill right now.

I just found myself a bit fed up with the amount of boilerplate involved in wiring Redux to React, and so I set out to create something that was easier to use and understand.

I'm interested in any suggestions, advice, and opinions people have for it. This is my first time creating a project with the intention to maintain it - so I'm eager to see what becomes of it!

https://www.npmjs.com/package/minimux



It is good thing to have options. Let the community decide the adoption.


I think it is a good thing that the React community has come together around one flux library, and it's bad to promote an alternative unless it solves a problem that would be hard to solve with Redux. Saving a few lines of boilerplate just isn't enough of a win. Starting an open source project is a great thing to do, but why not try to solve a problem that isn't already solved?


Unfortunately try as I might I've yet to think of a problem that isn't already solved. Of the literally hundreds of ideas I've had for libraries or frameworks or toolkits, I can google it and find someone has already made a package for it.

At this point I think "build a better mouse trap" is the best avenue for me to get anything accomplished. After all, if everyone followed the motto of "don't invent something that's already solved" we wouldn't have:

>React (replaced Angular, Backbone, Ember, etc) >Redux (replaced Flux) >jQuery (replaced Prototype, MooTools) >Facebook (replaced MySpace) >Google (replaced Yahoo, Ask Jeeves, Altavista, etc)

The list goes on and on. I didn't see an existing library as a reason to throw away both a learning opportunity and a fun project.


Not everyone can build stellar libraries that solve critical problems in their first go. Waiting for the ideal problem to solve, results in just another form of doing nothing, inspite of good intentions. When you reinvent the wheel and make it a little better, the library might or might not survive but the developer will learn essential skills that he/she can apply when she encounters an unsolved problem. We need to be immersed in tech for sometine to be able to identify critical problems.

One thing a developer could do instead of reinventing the wheel is to contribute to open source projects that need help.

Yet, creating a library from the ground up by oneself has its own merits in terms of identifying holes in your process and learning new skills


Maybe the parent is scared of another JS library fragmentation. Let's all use the same thing even if it ain't perfect has it's merits.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: