mjackson

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.

Hi, one of the authors of the router here :)

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.

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.

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?

That sounds like a terrible design decision.

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.

Co-author of ReactRouter here.

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.

http://vimeo.com/2723800

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:

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.

This is HUGE!

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.

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.

That should be part of your build system, not your package manager.

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.

No. ;) There is a Mac desktop client but the app will be available on the web as well.

Thanks for the tip! Just updated by profile.

Hum is able to both send and receive emails. People who receive stuff you send over email will be able to reply using the usual reply button, but it's not a full-fledged email client. The email integration is there to make it easy for folks who'd like to use it with their existing network of email contacts.

In addition, every Hum user gets an email address at letshum.com that they can use for incoming email.

You make some excellent points about using email in a support organization. To be fair though, Hum isn't designed to be used by employees in a call center.

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.

Hey all! Co-founder of HUM here, and happy to answer any questions you may have about it. We've been cranking away on this product for the better part of the past year and are very excited to be rolling it out over the coming weeks.

Huge congrats Sam! I think this move makes a lot of sense for a lot of reasons. You've been cranking out some really great stuff lately. Best of luck to you and YC!

On a project that I'm working I recently converted a ~260 line Rakefile into ~150 lines of gulp ... and our build is now almost instantaneous (took a few seconds to do with Ruby, mainly because we had to shell out to things like the less compiler). Oh, and we were also able to build our gulpfile.js in just a few hours after hearing about it for the first time.

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.

Thanks! :D

Please, you can make your point without profaning the name of Jesus Christ, a man whom many of us worship and who is dear to our hearts. To use the name of any sacred personage in this manner, as an expletive, conveys a lack of understanding and respect for other people.

I actually built this page a few years ago when I was working at Twitter during a hack day (bonus points if you can find the easter egg!). It's fun to see it on HN again.

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://engineering.twitter.com/opensource

The very next post on this blog is all about ... drum roll ... a custom framework that the moot team built, after deciding to not use any frameworks.

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.