Never found paddle shifters to be in the same league as a manual transmission even in modern high performance cars. There's always that bit of lag and delay with automatic that there isn't on a manual.
Yes and no. Sometimes it's not about the destination but about experiencing the journey. From the post it seems like the author extracted the value they wanted to extract over the years. Knowing when to give up is difficult, especially when you've sunk a lot of cost into the project and feel like you have to finish it. The thing is, you don't have to and it's perfectly acceptable to put it on hold indefinitely.
In the end you'll still have all those experiences with you and that's what you paid for with your time.
So long dear Wii U ! I'll always play and update you with neat hacks at my place. Seriously though, I don't understand people. For me the Wii U had way better games than the Wii and I would never trade my Wii U for any Playstation or Xbox. Smash Bros is way better, Mario Kart is way way way better (the best Mario Kart ever?)... Just lacked a really good 3D Mario Game.
I've been using this library to read screenshots of Pokemon Go to automatically calculate Individual Values for each Pokemon[1] It's worked great on desktop, but on mobile safari where it matters most the library causes the browser to crash :(
I would love to be able to make a custom builds of milligram by shedding some of the modules I don't care about. This could also open it up to other modules being added like Modals or whatever.
I'll take you up on that offer. Having comprehensive examples, documentation, and tutorials is something that sets Alt apart and I'd definitely like to have more of it.
Alt author here. I've actually begun to integrate some of the microflux ideas into Alt itself. Alt already has a lot of the benefits mentioned in the post: time travel, revert, record and replay debugging; but stores as reducers and having them not own state makes for clean code. However, I don't think one size fits all here, some stores are good as reducers of state and others fit a larger role. There are actually many different types of stores that get created in an application. This is really powerful but also confusing for beginners coming from MVC.
Anyway I'm excited for what the future holds for flux and excited for relay.
Five thirty eight's website loads in the ads, images, and even tweets before it loads in the actual content. This is completely backwards from what a web experience should be like.
Alt[1] has isomorphic support but there are some trade offs such as you're unable to use actions on the server. But you can still keep your stores as singletons and have them be concurrent. I'm still juggling on different ways to tackle this problem to offer more flexibility. There are a couple of example apps sitting in the iso[2] repo which is an isomorphic helper class.
This is pretty cool. There have been a ton of flux frameworks floating around lately, glad that there's an app that deals with async data to be able to compare each on their merits.
OT: This is the first time I hear about tab for a cause and it sounds very interesting. However, their Chrome plugin requests permissions to "read my entire browsing history". The privacy policy doesn't explain why this is needed, does anyone know?
Very nice, this is a great write up on an intro to flux. It feels like a lot of the learning curve on flux is spent trying to figure out exactly where to query data: in the actions, the store, or utils? And I feel like most of the pain in starting flux from scratch is creating all the constants, action creators, and registering the dispatcher.
After you've got everything set up it's smooth sailing though and you live with no regrets. Getting up that first hill though is tough.
I like thinking of my actions as where I fire off everything that will be fetching data. Then I keep the stores synchronous so that their only job is to get data from the dispatcher and store it. This makes the whole application pretty easy to reason about.
The interesting bit of isomorphic applications isn't the fact that you can use JS on the server. For me, it's that you can keep all your UI and UI-related logic written in one language, and have your business logic, data fetching, and everything else in whatever language you prefer.
This has many benefits like code reusability and not having to write placeholders/render code twice -- in two different languages.