Skip to main content

Posts

You Might Not Need Babel

Babel is great, and by all means use it if it makes it easier to develop your application. If you're developing a library on the other hand, please take a moment to consider whether you actually need Babel. Maybe you can write a few more lines of utility code and forego the need to pre-process. If you're only targeting some platforms, you may not need anything more than plain old ES6. At the very least, make sure you know what Babel is doing for you, and what it's not. Some developers believe that Babel is protecting us from a great demon of code complexity when, in truth, browsers and node are pretty easy to deal with on their own. Let's take a look at some of the strategies for not needing Babel. ES5 is pretty okay: In the days when we used tables for layout and the debugger was named alert() , we would have been so grateful if JavaScript had the features that ES5 has today. If you truly need Babel you are not only a weak programmer, but also an ingrate. Face
Recent posts

How I got involved in Open Source

Uh oh, its almost the end of 2015 so I'd better put at least one blog post here for posterity! About ten years ago, I was at a startup I co-owned and searching for a way to easily create a nice-looking UI for a Windows-based utility. Since this was a Windows app, most people at the time would have chosen C or C++ as the language or used C# and a framework like .NET. Or perhaps they would have gone old-school with something like MFC. Instead, we hosted the Windows HTML rendering engine in our own executable and built 80 percent of the app (including 99 percent of the user interface) in JavaScript and HTML. Basically, this would be a Cordova app today, but we coded it uphill both ways back then. A short time into development, it was becoming clear that there had to be a better way to organize all the DOM manipulation that had to be done. I looked around and tried a few libraries available at the time, but they seemed a bit ugly and weren't helping that much. Then, almost ten

A year with Modern.IE

For a little over a year I've been working with Microsoft on the modern.IE site. This week the site is celebrating having saved developers one million hours in browser testing. Some of the savings come from the free pre-configured VMs with real copies of the different IE browser versions. Just about all the popular VM software is supported on several different platforms. There is no substitute for using the real browser when it comes to compatibility testing, and these VMs are one way to do just that with minimal hassle. Further time saving comes from Browserstack. It provides convenient in-browser testing of just about any type of browser or device. Modern.IE offers a free three-month membership to Browserstack for IE versions. There are Chrome and Firefox plugins that make it really easy to quickly try out your latest designs on any version of IE, even if they're served off your local computer. Very slick. Most of my work on the project was done for the online compati

Haters Gonna Hate

I was saddened to come across this tweet by John Resig a few days ago. I know at least one of the people who has made--and continues to make--the attacks he speaks about. This person seems to have held deep hatred for John and jQuery for years. It's really unfortunate, because the attacker seems to be a smart and technically astute person. But he's also a bully. This bully's attacks tend to focus on two things: the quality of jQuery's code, and the quality of jQuery users. On the first point, it's telling that early in the project's life this bully created some tests that showed problems with jQuery. John asked whether we could use that code in jQuery's unit tests, and the answer was NO WAY. He leaves his own vitriolic form of jQuery "code reviews" around the Internet, but never makes constructive comments that might actually help jQuery improve. Helping people get productive things done does not seem to be his goal at all. Anyone can find pro

Please Stop the jsPerf.com Abuse!

According to many of the tests on jsperf.com , jQuery is slow. Really slow. The jQuery team gets bug reports from web citizens who've discovered these egregious flaws via jsperf and want them fixed. Now, jsperf.com can be a great tool when used knowledgeably, but its results can also be misinterpreted and abused. For example: Why doesn't jQuery use DOM classList for methods like .addClass()? There are at least three good reasons. It doesn't make any practical performance difference given its frequency of use. It complicates code paths, since classList isn't supported everywhere. It makes jQuery bigger, which makes it load slower for everyone, every time. But this jsperf shows classList is much faster! How can you say that? Well it's possible that test is running afoul of microbenchmark issues , and not measuring what it is supposed to measure due to the increased sophistication of today's JavaScript compilers. This is a big problem with a lot of t

Amazon: You Know Better

For the past few days, Amazon has followed me around the Internet with this one advertisement for a rolling suitcase. That's because the wheel bearings on my old rolling suitcase are just about shot, they're all screechy and wobbly. It's been a good suitcase and traveled over the world, but it's just worn out. So I went over and bought a nice suitcase from Amazon, using my Prime membership. But I didn't get that suitcase, I got a different one. Amazon knows perfectly well which suitcase I got, it was delivered today, and it's nicer than this one in my opinion. Yet Amazon continues to show me an ad for that suitcase as if to say, "Are you sure you made the right decision?" I imagine that the infrastructure that Amazon uses to determine what product to show is pretty awesome technically. Yet Amazon is doing significantly worse than if it just showed a random product from some category other than rolling suitcases, and they should know that. My

Tragedy of the WebKit Commons

With Opera announcing that their future products will be based on WebKit, the Internet is abuzz with discussion about what that means and whether it's a good thing. Looking at it as a jQuery developer, it's a good thing if it gets WebKit participants to fix bugs and update older implementations. I can't be optimistic without some evidence that things are really going to change. We don't know how many of Opera's core developers will move to WebKit development, but the press release isn't encouraging:  "The shift to WebKit means more of our resources can be dedicated to developing new features and the user-friendly solutions."  I suspect they want some cost savings by eliminating Presto technical staff, or -- in the most optimistic case for their employees -- refocusing existing staff on the parts outside WebKit core that make browsers different. Opera did  land their first WebKit patch  so they wanted to make a statement that they weren't gettin