No. Limited support, nonexistent team, it's trying to do far too much in one module to jive with the JavaScript philosophy, and it's got a janky old, awkward jQuery feel in the age of the SPA.
It's not really a matter of whether or not the thing stands on its own merits - it's cool enough and might've even gained more traction if it had come sooner - it's just far too late to the game with far too little to show for it.
1.0, 1.5, 1.6, 2.0, or 3.0? Or are they prancing and skipping straight to 4.0 now? Can't keep up. JavaScript, TypeScript, or maybe in Elm just because?
Angular is eternal reoccurrence of overengineering prematurely brought to term and I'm not sure how many whiny medium.com articles we're going to need before we quit getting excited about the next radical departure from productivity to learn Angular 8.5 in wooscript 3 with xyz static typing bundled with packrat 2.
I can't say I see much benefit in bolting another random library on top of my web stack.
Also, this seems like it's really going out of its way to twist familiar redux patterns into something OOP and class-based. Mashing together these wildly different mental models to solve the same state problems does not pass the "smell test."
I went from making dumb troll posts to legitimately enjoying the site very quickly: good content, effective mods, and sharp users quick to either add useful addendum or call out what doesn't belong. Keep up the great work!
Yes. Elm is very nice, but I agree with your sentiments.
I am seeing a lot of folks on github with elaborate transpiling features configured for up to basically ES8, who are also still pulling in all of lodash for one line utility functions like "times."
The ease of expression that newer ES grants in working with lists and objects makes much of (granted not all) Ramda and lodash unnecessary. We're going to have to grow into our new standards a little bit yet, but doing so will help trim off the fat going forward; gradually these things will be made easier to understand for newcomers on-boarding.
This is a community whose posts explicate or challenge some JavaScript feature/perspective/library. There is a tighter technical focus. What you've posted is pleasant and encouraging, but not pointed enough to be considered relevant.
I was skeptical at first. However, having actually used it now:
- It's *fast*. I've got my full "stack" of modules for web development pulled down while npm is still choking away. Try it, it's NOTICEABLY faster than stock npm.
- It's compatible with npm and there's little to learn. npm init? yarn init. npm install --save? yarn add. Need something particular from npm? No problem, keep using npm on the side.
Fair enough on the first point: I am perhaps too much of a purist with separating concerns. It's not enough to put me off of trying Vue.
The size difference is very impressive ... if you don't mind, about how complex was your finished app and how large was the bundle versus something similar you have done with a React (and friends) based app?
React and redux have achieved their prominence by holding their resolve with the Node philosophy: do one thing and do it well. React provides us with natural language and tooling for composing declarative interfaces (be they web component, native UI elements, or experiments like react-music) without seeking to blur its own lines. You've got a view.
Redux establishes the same clear line: here lies the data. Either describe its changes, provoke them with middleware, or implement an alternative side effect model (redux-observable, redux-saga, and friends) but here is absolutely not the place for your view.
Redux without React is still a monumentally useful library that falls under the "simple but profound" umbrella, which is also true of React sans redux.
I highly doubt that Vue will manage to provide a superior model for both of these separate but foundational concerns. When one also considers that React and redux both excel in their composability and that neither library entails commitment to the other (to use React and Redux gains you two ecosystems of community support and development, neither married to the other), it seems to me that Vue will become another Angular (beloved and used wholly by very specific shops) with a few less trappings.
It looks clean enough, and as a library even quite nice, but in the bigger picture it is trying to solve answered questions with poor solutions: why are we trying to replace what has been effectively & elegantly decoupled with something monolithic?