Well I'm glad they at least released a public postmortem on the incident. To be honest, I feel naive saying this, but having worked at a bunch of startups my whole life, I expected companies like CrowdStrike to do better than not testing it on their own machines before deploying an update without the ability to roll it back.
I think that Redux provides two things that people like:
1. A pattern to organize their state in that was testable and repeatable
2. A way to maintain global app state without prop drilling
I think that (1) is actually the reason that many people pick Redux in the first place. The amount of global, app-wide state in /most/ applications is fairly small IME. I think that the ReasonML team (which works semi-closely with the React team) is banking on things like Apollo, "suspense", the new context API and other things to further reduce the need for a global state store like Redux.
The ReasonReact devs are trying to follow the principal of least power in providing something that solves (1) for component-level state, which solves the 80%, and wait for the rest of the ecosystem to shake out for the rest.
Someone who knows React can easily be using ReasonML. So to me, the question is, why not? You can get most of the features of ReasonML with 3rd party libs - TypeScript for type safety, Redux for state management, and Immutable. However, when I look at the build time comparison, I doubt you'd get something as fast with JavaScript, at least not today.
Typescript, Redux, and Immutable.js work together as a pretty compelling stack, but they involve a fair bit of boilerplate compared to Elm or ReasonML.
Elm provides type safety, immutable data structures, and state management in a very compact but readable way. In fact, Redux was strongly inspired by Elm's state management.
All of these stacks are perfectly acceptable choices, so it comes down to a matter of personal preference. I'd encourage everyone to spend some time with Elm and ReasonML. I find them to be productive and very enjoyable tools.
PureScript deserves a mention in this list as well. More full-featured and general purpose than Elm, cleaner design than ReasonML. Prolly the smallest community of the 3.
I played with PureScript a little. It has advanced type system that captures a lot of semantics of JS allowing easy interobility with JS ecosystem. But that comes with a huge price. With all those monads and monad transformers interacting with JS it is easy to end up with stateful mess. Surely, it will be typed and functional mess, but still it is hard to maintain with all state pieces spread through code hiding in lambdas.
With Elm the situation is very different. All your code is pure. The runtime hides the state management and the only way to interact with JS is via message passing. The end result is code that is extremely easy to follow, maintain and debug. Moreover, as Elm style and tooling discourages using lambda-style callbacks with opaque state, all state is very explicit and often just by looking at the state data structures, one often can grasp what the code is doing. It is almost like code follows from the data structures.
Elm is a lang and a FW in one. Very opinionated. Very batteries included.
PS is a lang. It compiles well to JS, but there is no friction against making it compile to native, apart from the time it takes to maintain that compiler backend.
On top of PS you may pick a FW. Some have React.js under the hood, some follow more closely The Elm Architecture.
Elm is also a language. Surely it's libraries and runtime assume JS and DOM, but nothing prevents creating other ports of the language or creating alternative libraries.
And yes, Elm is opinionated. But that is a consequence of being very simple and pure functional language. As its typesystem does not support using monads or effects to model state with code similar in style to that in non-functional languages, one inevitably ends up with a runtime similar to Elm browser bindings in any Elm embedding.
Essentially Elm is opinionated because its pure functional style is the only style supported by the language with no escape hatches like the do blocks in Haskell or PureScript.
I love Purescript, but I'd be hesitant to recommend it to anyone without a Haskell background. There's a lot more to learn in Purescript, and I'd worry that it could discourage people who are new to the Haskell family of languages.
I'd advise starting with Elm to fall in love with the development experience and wonderful error messages, and graduating to Purescript when you need more power.
I like PureScript a whole lot. Something that ClojureScript and Reason seem to have on PureScript is really efficient persistent structures being the default, at least if I remember correctly. It's been a while, but I seem to recall PureScript giving me nice, functional syntax that under the hood did lots of native JS object / array copies.
Nowhere in the article does it say that the POST data was in the URL. As I understood it, he was editing the request body before the request was sent to PayPal's server.
What are the challenges of migrating to https only protocol? I have done it before, not on wired.com scale though. We use AWS and it's not that difficult to start supporting https and have all http requests redirected to https. Can someone explain why it took them a year to do this?
This is why, when you have a site the size of wired.com it's not a matter of changing the binding on your webserver.
You need to go over the entire site including historic
content to make sure that all the links are HTTPS.
You need to go over the entire code of the website and make sure all the JS requests are over HTTPS.
You need to make sure all the adds and 3rd party content you serve are over HTTPS.
You need to make sure all of the SEO and tracking still works.
You need to make changes to the CMS and how you roll out content.
You need to adjust your CDN and scalability to support HTTPS.
You need to update your redirects, sitemaps, search and more importantly make sure that you handle search engine redirects properly because it would be probably months until the search engines update all the links.
You need to make sure all your syndicated and affiliated content over the past few decades that is still linked somewhere will redirect properly.
This isn't a simple task, this is probably on the same level of complexity as updating your CMS and URL structure while preserving all the historic content, links, syndication, and search engine results.
I really like the direction this browser is going in. I noticed I cannot go back/next using a mouse or keyboard (though i can imagine one would be able to swipe to do that).
