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.
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.
> 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.
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.
Using Go (or Scala or Java or whatever) doesn't magically scale a large system.
Scaling problems in large systems are rarely solved at the micro level, i.e. you don't "scale" by simply gaining the ability to run more operations in a single thread. This is always the problem with "language X is more scalable than Y" debates. From my experience scale has little to do with language, everything to do with how you use it.
This post brings to mind another written by Alex Payne a few years back about scaling in the large vs. scaling in the small:
The danger with making hand-wavy claims with very few technical details is that it perpetuates the notion that there are certain magic bullets out there that will magically make your system "scale" if you use them. In the past few years we've seen quite a few large companies in SV and SF make the switch to some shiny new language (Scala, anyone?) only to find several million dollars and many months later that they're still having conversations about how to make stuff scale. Only now they're talking about making it happen in a language that is fairly new to their organization and with which they have only a few real experts.
> With the $18,000 fellowship, Gan will collaborate with industry and researchers around the world to work on new breakthroughs for data storage devices, and also see how his existing research can be used on a larger scale to rapidly improve the capacity of optics-based information technologies.
$18K seems like a drop in the bucket for powering this kind of research. Dr. Gan needs someone to introduce him to Kickstarter.
Hats off to you guys as well. That's a TON of work. :)
What % of Dart's development is sponsored by Google? Not trying to get a dig in at you guys, but it's also interesting to note that Elixir has come this far without the financial backing of one of the wealthiest tech companies in the world.
I'm constantly impressed by the level of execution of the Elixir project. In ~3 years they have accomplished much more than many other language ecosystems have to date.
It's great to see the core maintainers understand that you need MUCH more than just a compiler, runtime, and std lib to create a truly vibrant ecosystem. The Elixir project includes a standard way to do templating, a powerful and robust shell, a very full-featured unit testing library (not just assert statements), a standard logging system (this is sooo often overlooked), and, to top it all off, a build system that also lets you manage dependencies!
I honestly can't name any other ecosystem where you can just jump in and all these problems are already solved for you by the core project maintainers, instead of by 3rd parties competing for mindshare. It's truly refreshing because it gives the community a common language and toolchain to work with and get stuff done.
Hats off to everyone involved! You guys continue to amaze me.
tl;dr: "We want to build isomorphic apps, so we wrote a new package manager"
Coupling the goal of building isomorphic apps with the need for a new way of managing packages to accomplish that goal doesn't make any sense. How you install packages and manage dependencies has absolutely no bearing on what you can or cannot do with those packages.
In other words, you can write fully isomorphic apps using npm as your package manager. We're already doing it.
> FRP streams go beyond promises by allowing many returned values. This is pretty nice, and shows how FRP is at least as powerful as Promises.
The fact that you can only return a single value from a promise is a feature, not a limitation. In synchronous code, you can only return once from a function. In asynchronous promise code, you can only fulfill the promise once. There's a parallel.
If you want to "allow many returned values" you can just use a callback. You hardly need a "stream" for that.
Although it's not quite the same as a native app, we already have built in support for desktop notifications on all browsers that support them, including some older WebKits.