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.

Ah amazing, thank you! I had been doing it with https://rocketgraph.com/reports/21-discover-weekly-archiver but the archived playlists live within their web app rather than Spotify itself, so I never actually looked at them!

I was going to say the same, Discover Weekly frequently really impresses me with some of its selections and I have discovered some excellent artists through it. I'm into electronic music - not what I would consider really obscure stuff, but certainly not mainstream - and many other recommendation systems seem top lump anything electronic together with mainstream "EDM" etc. (which is nothing like what I enjoy) whereas Discover Weekly makes intelligent recommendations of quite obscure stuff.

I assume it uses some combination of social data (e.g. music listened to by people who listen to similar artists as you) and the intelligent classification ability they purchased when acquiring Echo Nest. There was quite a good write up about it - I think it was one of these two: http://www.theverge.com/2015/9/30/9416579/spotify-discover-w... or http://qz.com/571007/the-magic-that-makes-spotifys-discover-...

I just wish it would save my previous weeks' playlists as sometimes I forget to listen to them and then they're gone!

I've been using the v2 beta (along with https://github.com/jhudson8/react-chartjs/tree/chartjs-v2) and have been really impressed with it in general, thanks for all the hard work!

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.

Yeah, you are right. It's just a particularly annoying bug because: 1. It broke my phone pretty fundamentally, 2. It was a third party app that broke core functionality (in a roundabout way), which shouldn't be possible on iOS, 3. Lack of response from Apple, 4. Such a bug would be much lower impact on Android due to (IMO) silly restrictions on iOS. These factors combined with a lingering slight dissatisfaction with iOS has left me a bit annoyed (but I'll probably forget all about it soon!)

It's happened to both me and my girlfriend. It's not very common but seems to happen sometimes when software is updating when it has a good signal/wifi and you move into an area of no signal. Having been caught out a couple of times being unable to access important apps because of it (one time being in an unfamiliar area with a half downloaded Google Maps and insufficient signal to download the app again), I just don't risk it any more... Which is a shame as otherwise it makes sense to stay up to date obviously.

I did report this as a bug to Apple, who requested a device log of some kind when it next happens, but it's hard to reproduce manually.

Yeah pull to refresh on Mail is dodgy, but it always has been for me. Seems to work on the second or third try...

You're right, I guess "stability" is probably more accurate.

At the end of the day, it represents app(s) breaking the phone in very fundamental ways, in spite of the sandboxing iOS enforces (obviously this is a different vector in reality, but from a layman's point of view the end result is the same), in a way more severe than any Android app (which arguably have a reputation of being "less secure") has broken that OS as far as I am aware.

This stability/security was one of the reasons I've stuck with iOS for so long, but this particular issue has forced me to reevaluate my thinking somewhat, as I'm sure it will for many others.

Interesting, I am fairly certain the problem didn't surface until a few days after installing 9.3 although I could be wrong.

The current theory according to the article is that booking.com's app downloads a 2.4mb file of links for its "universal links" data (that annoying thing where you get taken to an app rather than a website and you can't disable it without removing the app...) which causes the database to slow down/become corrupt.

Therefore if you've not got booking.com's app installed, you should be okay (for now). Needless to say the fact that a third party app can break such a core OS feature rather shatters iOS's reputation for security above all else...

Your thoughts echo mine exactly (right down to submitting a story that got no votes!).

The fact that this kind of bug would have a lower impact on Android (i.e. wouldn't disable major functionality due to the ability to switch out default apps), along with a general sense that Apple's software quality and support is becoming less reliably good (I would certainly have expected a quicker official response to this issue) and a slight feeing that Android is creeping ahead of iOS in terms of interesting new functionality is making me seriously consider the switch (partially as a kind of "protest" move, partially because I'm really annoyed about a major part of my phone breaking randomly, and partially because I'm curious to try it out), which I definitely wasn't seriously giving any thought to before this. Could work out to be a good thing in the end ;)

Good to hear someone has got to the bottom of this. Been unable to use Safari for a few days due to it. I haven't updated any apps for months (I don't trust auto update to not leave my apps in a half downloaded state so I just let them mount up until I eventually download hundreds of updates!) so iOS must periodically check this list automatically rather then just when an app is updated/installed.

The combination of a lack of an official response from Apple yet, the fact that this was apparently found by beta users (not that the issue is related to 9.3 directly, but it was reported as a beta issue by some), and the inability to change default browser leaving my phone in a pretty broken state has got me seriously considering a switch to Android though, where at least such a bug could probably be worked around through changing defaults or worst case flashing a new ROM.

The iOS 9.3 release suggests Apple's QA process is rather lacking and incidents like this won't help confidence in their devices - it's okay for users who know how to work around it and understand what is going on, but my parents would probably think the whole internet was broken!

Rant over, glad to see this on HN as it has been p*ing me off for a few days :)

OP here, posting this as I am experiencing this issue with links from e.g. Google on Safari, and links from in-app webviews. I thought the MacRumours link shows the extent of the issue but happy for the link to be changed to a more reliable source if there is one - I couldn't find anything.

Shocked that such a huge bug could slip through making a major part of the phone useless! It actually makes me reconsider my loyalty to the iPhone as I thought stability was one of the key advantages of Apple's closed/limited device combination ecosystem, but if such a bug arose on Android, I'd at least be able to change the default browser.

Workaround seems to be to use Chrome for now but that doesn't help with in-app webviews.

I'd say learning is a bit different, it might benefit your current employer but it also benefits your future employment prospects so it makes sense for you to study it in your own time. Working on your employer's work probably doesn't.

I've thought about this too, but I'm not sure I've got the patience to listen to articles read in TTS voice.

Anyway, on iOS if you enable voiceover you can read the entire screen by swiping down from the top with two fingers (I think - check the Apple website for accessibility information if not!)

That's interesting to know! Thanks

  So it just leaves you in this limbo zone where you don't get to use the features of the native language that make up for it being so crappy, nor do you ever get to use the features of the transpiled language that promises to keep your code easy to modify over time. So that's what I mean about "worst of both worlds".

In an ideal world I'm sure a lot of us would love to work with Elm, but the reality in a commercial situation is often that the choice of language is driven by factors like: how widely used/well known it is, what the availability of libraries for it is like, how easy it is to hire developers with experience for.

This unfortunately makes languages like Elm and Clojurescript unlikely to be chosen in a lot of situations (e.g. as I understand it, the JS interop story with Elm isn't amazing, so you can't just use JS libraries with it).

Typescript is close enough to plain Javascript to not scare people off (I'd be willing to bet any JS developer could pick it up in a few hours) and can almost be considered in the same light as vanilla JS in such a decision, yet brings with it the advantages of a fairly decent type system.

As I've said elsewhere, it's definitely not perfect, but for developers in a position where other, more "esoteric" compile-to-JS languages aren't likely to be accepted, Typescript probably represents the best choice of bringing a decent amount of sanity and predictability to codebases.

(This isn't meant to be having a go at the parent BTW, it's just something I've been thinking about a bit and the comment jogged my memory!)

I guess the point is that with Babel you can enable so called "stage 0" language features, which aren't in the spec yet but someone has created a Babel plugin for (e.g. decorators).

With Typescript, you can't do this, because the code has to pass through the Typescript compiler first, which doesn't support (most of) these features (e.g. it does support decorators IIRC) so will throw an error when it finds an unfamiliar language construct, and it doesn't have a plugin architecture like Babel, so you can't add them in that way.

One example is the spread/rest syntax which is sometimes used in React projects isn't fully supported in TS: https://github.com/Microsoft/TypeScript/issues/2103.

I should point out you can use Babel and Typescript, so the Babel processes the output from tsc (needed for using e.g. async/await at present, as tsc can't compile these down to ES5), but tsc has to run first to make the code into valid JS (on this note, I was surprised how easy it was to remove TS from a project - Babel will ignore most of the TS specific stuff such as interface and type declarations, as it already strips them out for Flow compatibility and the syntax is largely the same)

How are you finding Nuclide? When I tried it a few months ago it seemed pretty slow and unstable, and eventually ended up consistently using all my CPU after a while. There wasn't a great deal of documentation/help setting it up available (true of Flow as well to a lesser extent), which was why I chose TS at the time, but am definitely interested in seeing how Flow is progressing.

You may or not be right, but Typescript seems to be gaining a reasonable amount of attention and traction outside Microsoft, so I suspect its type system may be "good enough" to add a decent degree of type safety while still staying close enough (for better or for worse) to vanilla Javascript that developers, CTOs, etc. aren't put off by the perceived difficulty/risk of a totally new language (also I guess the Microsoft backing counts for something).

There are enhancements to the type system on the roadmap, for example support for non-nullable and variadic types: https://github.com/Microsoft/TypeScript/wiki/Roadmap

Typescript may not be perfect but I'm glad to see it getting more attention as I think it can bring a significant quality improvement to a code base for a fairly small investment of effort.