mjackson
Joined 14 years ago
Karma
516
Submissions
91
Member since
Mar 30
Co-founder of React Training. http://twitter.com/mjackson
View on Hacker NewsRecent submissions
Comment · 5 years ago
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.
Comment · 10 years ago
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.
Comment · 10 years ago
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.
Comment · 11 years ago
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.
Comment · 11 years ago
> 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?
Comment · 11 years ago
> 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.
Comment · 11 years ago
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.
Comment · 11 years ago
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.
Comment · 11 years ago
> 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).