tommyd

And likewise I feel like a broken record, but try MobX instead of Redux. Much quicker to get started.

Regarding state management, have you tried MobX? It makes state management almost ridiculously simple. I've noticed a slight performance hit using it for deriving values for 60fps animations on React Natuve but in normal usage you'd never notice.

Good point. I suppose what I meant was more that types are at the core of Elm and pervade every part of the language, whereas TS/Flow are adding types on top of a dynamic language and there are parts where it may be difficult or impossible to maintain type safety to the same degree (especially when interacting with non-TS/Flow code)

Absolutely agree, this is one of the biggest benefits I have found since I started working with Typescript (that, and the ease of refactoring).

Of course Flow/Typescript's approach to typing isn't as complete as Elm's, but you can still gain some of the benefits by using one of them; and for many of us, introducing Flow/TS at work is a lot more likely to happen than introducing Elm.

I thought the very same thing, as I can see the benefits to both having a single atomic commit for ease of reading history, and to being able to see the individual commits that made it up to avoid losing valuable information about changes.

It turns out that the Github "Squash and Merge" option for Pull Requests does basically this – you review the PR as a bunch separate commits, when you click "Squash and Merge" a single commit is created in the target branch with all the commits squashed, but you can still go back to the original closed and merged PR (e.g. by following a link in the commit message) to view the individual commits.

Obviously this doesn't help if you want to bisect among more granular commits, but (without having actually used it), it sounds like a good middle ground to me. The previous workflow I was used to involved squashing and force pushing to your branch, therefore overwriting the individual commits in the PR for ever.

Thanks for the detailed reply, very helpful :)

I wasn't trying to raise an issue at all, merely state that Spacemacs isn't as obvious to a new user as Atom - but I'm not saying that that's a bad thing, obviously (Spac)emacs has a lot more power under the hood potentially and I am sure is worth the additional effort to learn.

I have to say I'm impressed with what a good job you have done of making it user friendly :)

That's a fair point, didn't even occur to me!

> Honestly, and sorry for sounding rude, to me it just seems like you intentionally tried to not understand in order to prove a point; Just because in your mind you have this idea of emacs just having to be inferior in some way.

Not at all and I didn't mean it to come across in that way, apologies if it did. Thanks for pointing out those things - I actually for some reason didn't think of using the menu bar at all, I guess because it looks like a non-GUI app. That's my fault anyway!

I was just interested in the "absolute newcomer" user experience, as that is how a lot of people will judge things, which for me after a few minutes was "I can't work out how to do what I need to do" and so I stopped. I'm sure that with an hour or so playing around, I would get used to it, and I intend to!

I downloaded and tried Spacemacs out of curiosity, after seeing your comment.

While I'm sure it adds a lot of usability features compared to the default Emacs config and it looks pretty cool, it's nowhere near as immediately accessible as Atom or Sublime - for example, I have no idea how to close an open file without Googling whereas in Sublime or Atom it's either click the "X" or use the standard Cmd-W shortcut. I also have no idea how to open a project or search for a file, and don't really know where to start discovering those things, whereas in both Sublime and Atom you can browse through the menus, or hopefully quickly discover the Cmd-P command launcher which lets you type a command.

If I wasn't somewhat familiar with Vim, I would have absolutely no idea what was going on as by default it uses Vim's modal keybindings. I also noticed an annoying lag when pressing spacebar to bring up the command list thing - slower than any lag in Atom!

It does look intriguing and I'd love to learn to use it more, but I don't think you can really say the usability of Atom/Sublime and of Spacemacs to a new user are anywhere near equal, never mind "how would they justify their choice?"!

I understand the point here and agree to some extent, but on the other hand I think using a standardised set of emojis makes sense for cross-platform communication apps such as Whatsapp, as I think the meaning of some of them is reasonably subtle and those subtleties are very much influenced by the specific design - for example, the Apple "person with folded hands" shown in the article clearly represents prayer to me, whereas the original Google one looks kind of creepy with its screwed up face. I found this to be an issue when I had a windows phone - for better or for worse, emoji are used quite a lot, and I sometimes had to think back to the iOS equivalent to make sense of them, as they looked so different.

In my opinion Apple's take on emoji is both the most visually attractive (the proportions of the old Google ones are way off and the "slug" creatures quite visually unappealing) and the richest, so it's no wonder they have become the de facto standard. In fact, I'd wager emoji wouldn't have taken off anything like as well as they have if everyone saw the original Google versions, for example, as they lack the "cuteness" and charm of Apple's versions.

What might be nice is if Apple were to make them fully open source - I've wondered before what the legal status of apps like Whatsapp embedding them in their app is.