I love mobx (definitely not one of the 58), but I would use redux on large apps (maybe, more than 15 pages?), especially if you don't care too much about performance. Redux has better debugging, forces more structure to the code, has a immutable data story, and there are more resources on the net if you need to bring developers up to speed. There are some configuration options for MobX that force the user to be more organized, but redux still feels more structured.
That being said, MobX is absolutely my go-to state management library now - it's probably the easiest free FPS you'll find anywhere, it's ridiculously easy to write, and it results in fewer LOC.
Out of curiosity, why do you say "don't care much about performance"? Redux can be _extremely_ performant, although it does take a bit of thinking about how your data is organized. I've got several articles discussing Redux performance [0] in my React/Redux links list [1]. In particular, check out Dan Abramov's PR to a MobX/Redux benchmark [2], and the article "High Performance Redux" [3]. Finally, the upcoming React-Redux v5 release shows noticeable improvements in a variety of scenarios [4].
Any specific issues with Redux performance that you've noticed?
Second that, MobX has been a total game changer for me. Used redux and really like the philosophy of it, but overall feel mobx is much easier to use while accomplishing just as much, and the simplicity and lack of boilerplate actually makes reasoning about state, testing, etc much easier than redux. I disagree about large apps (switched to mobx on a large app now), but I can roughly see what you are saying. Still, I think MobX is great on large apps
I really wish that MS would release typescript as a collection of plugins for babel that would handle only one thing at a time (eg, the type system). Having my production build, es6 transpiler, type system, JSX compiler and so on (including a bunch of features I would rather didn't exist at all) all in one package feels like a failure of separation of concerns.
I understand that people find Babel's plugin ecosystem confusing and intimidating (it is), but I don't think a separate monolithic typescript that reimplements popular babel functionality is the answer.
I suppose the problem is that I see typescript as the fragmentation. If MS leverages babel (they can even keep shipping TS as their own thing if they want, I just want them to provide babel plugins), we can all use that and focus on making it as cross-compatible and streamlined as possible. (Well, really, we can focus on providing a single well-documented on-ramp to new javascript developers, which I think is the main problem and the one MS set out to own with typescript.)
Right now, we have the typescript ecosystem, the babel ecosystem, and the other wannabe ecosystems. If I like Typescript's type system but want to use babel for async-await (for instance, I'm aware it's in TS next), I'm basically SOL. Babel has more end-users (AFAIK), generally has the first/only implementation of <feature>, and my impression is that the surrounding development community is larger and more active (typescript stuff tends to come down from On High).
For instance, you can use https://github.com/gcanti/babel-plugin-tcomb to get run-time type checking with babel/flow for free. That's really cool! Unfortunately, the same is not possible with typescript (AFAIK), because MS decided that was out of scope. If Typescript was offered as a babel plugin, somebody else could implement it for typescript and we could all be happy.
If you implement TypeScript as a Babel plugin, you would likely lose all the superb IDE support that TypeScript has. Which is one of the major selling points of TypeScript IMO. When your language is unstable like in a typical Babel setup, any number of features might be on or off, the static analysis done by IDEs becomes almost impossible. Performance would be affected too.
Microsoft has absolutely done an amazing job with typescript IDE integration. But are there any end-user IDE benefits to typescript over flow/eslint? (Not being snarky.)
I've been using both on separate projects (with MS IDEs) and haven't noticed anything major.
The design of TypeScript is explicitly so that it can provide a good API (called "language service") to IDEs and other tools. And not just "give me all the errors/warnings in this file" but also to give detailed information about the types at specific positions of the source code, and the whole design is so that it can efficiently recheck a whole project if you change one part of a file. One of the lead engineers of TypeScript talked about that in one of his techtalks (can't find the link right now).
im a Flow fan, but Flow's IDE support is pretty bad. WebStorm only souped it up recently, and aside for that, outside of Nucleide (and even there!) its pretty awkward/slow/clunky and in many cases downright buggy.
TypeScript's type system is very bleh, but its IDE integration IS pretty good across many editors (not just VSCode)
I think people like not having the usual Babel plugin/config + setup soup. There's value in all-in-one solutions with clear limitations. For example, TS doesn't implement JavaScript stuff below stage 2 while many devs liberally use stage-0 and stage-1 features with Babel. Some prefer TypeScript's way.
Babel is temporary solution and we should all remember this. Babel should ideally be obsolete in 2-3 years when IE11 will get eradicated by MS. Babel imo is pretty bad idea, I think its name imply this as well.
I can't see how this would help things. Trying to separate it all out would surely lead to lowest common denominator support in terms of strong typing if things were optional (hard to design a type system when you don't know all the features) and create further JavaScript fragmentation.
Honestly, this sounds like a big step backwards in UX if implemented widely.
I would really rather not have to manually install a million packages when pulling down dependencies - "npm install && npm start" and then going to grab a glass of water feels great.
The given use case of a master parsing library doesn't really resonate. A handful of extra kb on disk doesn't bother me at all for an all-in-one solution, and I've never really had the problem of not being able to find a parsing library on npm to begin with.
You do have to choose which packages you want to install at some point. When you do `npm install && npm start` it will still work as planned. The problem here address is for when you need to deal with a new issue.
If it were a handful of extra kb, I'd agree. Of the top off my head I can think of following file formats "somehow" suited for configuration: json, cson, properties files (java), yaml, xml, conf-files (Apache), ignorefile syntax, ini files.
Supporting all of them could be a reasonable goal to the community (looking at the packages in npm: it is an actual goal already).
A problem that I have with my article is that readers seem to get hung up on the config loading bits when I tried to use it as an example for a more-general problem.
Of note is that of these, I think only the elixir and ruby (?) solutions are distributed. Additionally, Phoenix channels are doing a lot of work that the other solutions aren't.
(Note: I support trigger warnings and think that they have a lot of use as a tool even outside of the typical context)
I'm in close contact with a lot of social justice groups, specifically ones based out of UC Berkeley. It's not super widespread, but there are absolutely individuals who abuse the concept of triggers as a way to give themselves pretext to be cruel to others, to control conversations, or just as something to get righteously indignified about.
This is an issue with the individuals involved and not triggers per se, but just as with other social technologies it's definitely possible to abuse triggers.
I'm using Electron ( shell? ) to make a simple desktop app. Certain things are much nicer, such as the ability to have everything be "owner draw" in a way that isn't as frustrating as using owner draw in the usual context. IE,
I can easily at a bitmap background to whatever component I want. I can control a lot of the look/feel of the UI with style sheets.
IMHO, React is another way of covering up 20 years of bad design decisions that went into web tech. React is the natural reaction to using a tree of text to represent data structures. If things were done right, React wouldn't exist.
By 'real modules' I mean things like DLLs that can be hot swapped at app start or at runtime.
The more I look into things like Atom, the more I am disturbed by what constitutes 'state of the art' in web tech.
I mean, react (and associated frontend technologies) are just a way of making it easier to write code within the constraints of browsers, which are honestly a small miracle. Yes, they're a pile of hacks upon hacks (the web was designed to share physics papers, not deliver complicated multimedia applications), but they let you write the same code for every major operating system, device, and form factor that exists and deploy it seamlessly over an unreliable network. It's shocking that everything works as well as it does.
And as programmers, everything we use is just papering over the horror of writing network-connected cat-sharing apps on weird-shaped bits of metal - why worry about a light abstraction over the JS build step?
My experience with Atom has also been sub-par, but Visual Studio Code is pretty cool and built on the exact same platform (electron).
I think you're the exact target audience for typescript, for what it's worth. It will give you type checking, IDE integration, compiler errors, modules, etc basically for free and is (not exclusively, and IMHO) built for people who find javascript distasteful.
While the cryptocurrency conversation online is dominated by right-libertarians, I think you'll find that a lot of hard/radical leftwing direct-action types are very much obsessed with cryptocurrency and structures like the DAO. I personally don't look at the cryptocurrency scene/DAO with anything more than bemusement, but I think that community is often presented in a very unpleasant light (look at the weird nerds!).
A more charitable stereotype might be that cryptocurrencies and automated contracts appeal to anyone who thinks that they can design (through their technical expertise) a better world than the current political elites. I'm not saying that they're right or that their line of thought hasn't been historically responsible for atrocities, but I don't think it's fair to paint them as sociopaths.
Certainly didn't mean to imply that you have to be a sociopath to like cryptocurrency! That would be unfair and ridiculous. I think it's more like an allergy to what one considers politics.
The benefits of cryptocurrency i've seen argued for in left libertarian circles don't propose some narrative where it supplants the current structures of government. I think a lot of leftists would reason (certainly, I reason this way) that cryptocurrency's much touted benefits are in conflict with capitalism and could not support capitalism at all. This is at odds with the right libertarian ambitions for the technology: right libertarians love capitalism and the crypto enthusiasts on that side of the spectrum think it would be great for capitalism! It's a fundamental disagreement. I've heard about bitcoin being used to great effect by left wing insurgencies like Rojava. It is useful in its current form as a subversive means of transmitting resources.
I'm not familiar with the left wing arguments for cryptocurrency as a transformative tool for structuring new societies. It sounds like technocracy and vanguardism and, well, we know how that's played out.
