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.
516 karma · joined March 30, 2012
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.
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.
You can easily load Mocha onto the page in your karma config using the karma-mocha plugin. Then, one line in your karma config and you're done. https://github.com/rackt/react-router/blob/53623216560e34fbe...
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.
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.
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).
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.
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:
https://al3x.net/2010/07/27/node.html
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.
Thanks to everyone at Facebook who worked on this. You guys are awesome.
Also: The fact that this is written primarily in OCaml (as opposed to JS) is an excellent example of people choosing the right tool for the job.
$18K seems like a drop in the bucket for powering this kind of research. Dr. Gan needs someone to introduce him to Kickstarter.
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.
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.
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.
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.
In addition, every Hum user gets an email address at letshum.com that they can use for incoming email.
Instead, Hum addresses a much more fundamental shift in communication patterns that is already in full swing. Conversations are getting shorter and shorter, and more to the point. Most teens I know never check their email. Many of them don't even have email addresses.
Hum combines some of the core organization elements of email, like threads and subject lines, with features that many people have come to expect from their more modern IM/text/Twitter client like instant updates, presence, typing indicators, @mentions, etc. It strikes a balance between the two that helps bridge the gap from email to a much faster and more productive medium.
I never went the Grunt route because I just can't get used to programming with massive, multi-tiered object literals. If you've ever seen a Gruntfile, you know what I mean. It's all configuration, very little real code.
With gulp, code trumps configuration. And the result is incredibly concise and fast. I would definitely encourage anyone who has been looking for a decent build system for JavaScript to give gulp some serious consideration. We were pleasantly surprised with the community support as well. There is already a wide array of community plugins for gulp that support many common use cases.
Anyone who is interested in Twitter's current open source contributions should definitely check out the open source section of their engineering site as well:
https://moot.it/blog/technology/riotjs-the-1kb-mvp-framework...
Sadly, this behavior is very common among those who have a hard time adopting existing libraries/frameworks. In the end, they almost always re-invent their own obscure wheel that does the same job.