Although esbuild has been out for a while now, I think it's relevant today because the benchmarks have been updated to include Parcel 2, which was just released earlier today.
Try to insert routing only when you need it. When you're ready for a router, react-router is a great choice. Lots of people are already using it with great success, and you'll find a great community of people willing to help you out.
Yes, I like this. It's important to learn what react is and why it's good for handling state in a component before you start trying to build the routing of a full web app.
Ah, great catch! I never see that error because that file is only loaded in browsers that don't have a native window.fetch. Thanks for catching that. Will fix right away.
Karma and Mocha don't do the same thing, so this comparison is weird.
Karma is a test runner. Use Karma to launch and run your tests in real browser instances. There is no better tool available for doing this.
Mocha is used to actually create your test suite. It's great at describing how your tests should run, with stuff like before/afterEach, it.only, describe.skip, etc. Use Mocha to describe which tests you want to run and how they should run.
As for file watching (also part of the OP) your bundler should be doing that. Use karma-webpack (or whatever tool you're using to create your bundle).
Finally- probably the best thing about Karma is its wide support in the community. You can find a Karma plugin for just about any other tool you might want to use, including launchers for hosted browser environments like Sauce Labs and BrowserStack.
I agree as well; I was confused as to how they benefited from switching away from Karma as a test runner. It seems that they simply replaced PhantomJS with jsdom, but in the process they lost Karma, which means that they can't run their test suite on other browsers.
Also, from first glance, I'm unable to see a performance improvement by not using Karma. It may be because they're using more tests in Mocha, but the difference isn't huge considering they're losing a lot of functionality.
As you can see from the article, this is not truly a comparison between Karma and Mocha, but I wanted the title to be intentionally provocative, to sparkle some discussion around the topic :)
We use test-automation for real browser testing but prefer to rely on quick and functional unit-testing, thus the choice to go with jsdom.
Regarding the community, you're right, there's a `karma-something` for every need.
However, mocha is pretty popular too, and getting momentum by the day. Also the fact that it simply runs on Node makes it quite easy to obtain what you want without extra plugins (e.g. coverage).
"wanted the title to be intentionally provocative"
Click bait adds no value to the discussion.
There's no either/or when it comes to karma/mocha. As the commenters above mentioned, it's best to use both. Mocha for quick unit testing, karma for in-browser testing.
In-browser testing can be automated to run on a wide range of browsers and platforms using integration tools such as Browser Stack.
By faking the DOM, you remove nerf the greatest advantage of client-side integration testing. Checking functionality under realistic circumstances.
> The centralization of information also worries me because it makes it easier for things to disappear. After my arrest, my hosting service closed my account, because I wasn’t able to pay its monthly fee. But at least I had a backup of all my posts in a database on my own web server.
He published this article on Medium? Isn't that a huge contradiction?
The author never said it was a good design decision, or even a desirable one. He only said it would be impossibly difficult to do in a purely functional program, which is worth considering. Whether or not it's a good design decision is irrelevant.
He's making the argument that functional programming is bad. If it were a terrible design decision then the language precluding its implementation (as he claims functional languages do) would be a positive or at least not a negative. So, he must be making the argument that it is a good thing, or at least a necessary thing.
Even so, the ML's all support this type of behaviour (with globals).
In the same way, we do not criticise functional languages for not allowing goto style control flow.
It is very relevant, because author tries to paint this difficulty as a bad thing. It isn't. If the language, or a tool, makes it hard to do bad things and makes it easy to do good things, it's good.
With regards to #2, I used to think that a fully sync render function was a limitation of React, but have come to appreciate the fact that React tries to restrict its concerns to a very small, but significant piece. We've been working on solving the async data fetching use case in the router over the past few months, working with the Relay team as well, and we're starting to converge on some ideas and patterns that we think will help. But it's my personal opinion that sync render isn't a problem.
Maybe of interest: Zed Shaw, creator of Mongrel, gave a talk a few years back where he mentioned that he was using Factor to create the slides in his presentation.
> The point of React is to mix HTML and JS together.
In React, there are no "templates." There's just JavaScript, and then more JavaScript that looks kind of like HTML (JSX). But it's all still JavaScript.
Also, FWIW, I find that one of the largest benefits of React is to have the logic and the representation of the markup inline, together in the same file. It really helps productivity by eliminating the context switching going from js to markup.
> We didn't need full diffing and batching of HTML
^^^ That's the point of React. You don't have to do the diff in your head (or in your code).
Awesome stuff James :) I've been having a lot of those weird client vs. server realizations myself. Still getting used to thinking about stuff that renders in both places.
I'm particularly interested in hearing about your ansible + docker setup. I've been using both a lot lately, and trying to figure out the best way to use them together.
