I recently decided to go down a rabbit hole of wanting to learn a new client side library. I was interested in learning more about libraries that aimed to have a minimal footprint even at the cost of providing a more modest API. For this site I have simple requirements, and I wanted to see how simple the ‘simple’ abstractions are these days.

Over the last month, I’ve been building a ‘fun’ project that uses CakePHP, TypeScript and React. While I maintain AssetCompress it is poorly suited for react or vue applications.

Recently I shipped a new feature to Stickler CI that enables users to extend Javascript and Python builds with additional packages. Maintaining review tool dependencies can be a drain on your team’s time. Stickler CI helps solve this problem, but used to come with a tradeoff of not being able to fully customize your style rules.

Stickler CI is a software as a service application that automates a tedious part of code review; enforcing consistent style and preventing lint errors. By integrating with GitHub, Stickler checks each pull request for style errors and post review comments when an error is found. This helps your team align on coding standards and provide more valuable feedback. Stickler is free for public repositories; private repositories require a paid plan.

If you’ve ever built a web application that wanted access to the visitor’s camera you know what a painful experience that can be. If used to involve flash or silverlight plugins or clunky java. Thankfully, browsers have started providing new API’s which are collectively referred to as WebRTC or Web Real Time Chat.

I try to keep fairly busy. Between work, being a dad, and working on existing open source projects, I found time to work on two new ones.

Xhgui2

Profiling is a very interesting topic for me. I love spending time sifting through results trying to find ways to make code run faster or use less memory. XHProf is a C-extension created by Facebook.

I recently re-discovered a powerful, but mostly hidden feature of jQuery. If you’ve used jQuery for any length of time you’ve probably used filter selectors like :input, :visible or :hidden. What you may not know is, it is really simple to add your own filter selectors. The secret lies in $.expr.filters which is an object of filters.

A project I’m working on requires displaying small data driven sparkline charts. The data is a basic set of data showing activity over time.

I’ve recently integrated static analysis tools into both my day job’s and CakePHP’s development process. Setting up static analysis tools is reasonably easy and can help you find problems before you even get to unit tests, or staging sites. They are also the ideal tool to help enforce coding standards, and best practices that can be checked by reading the code.

We use selenium extensively at work for automated acceptance tests. If you’ve never used selenium, it allows you to record and playback browser sessions and create integration tests from the perspective of a browser. Its generally a great tool, and really helps make sure we don’t release broken code. Recently, however I’ve found Selenium can have adverse reactions with jQuery.

You may have seen the Analog.coop site recently and found some of the easter eggs, like the grid hot keys. I loved the concept, and made a mental note to spend some time reverse engineering/rebuilding it for my own uses. Well it just so happens that the guys at Analog have released the #grid on Github, which is great because it made it easier for me to adapt the code and do some small improvements.

I’ve been working on a client project that involved some reasonable amount of SVG/VML work. In order to make my life more sane, I’ve been using Raphaël JS to do what it does best, which is provide a great API for making sexy vector graphics.

Creating ajax pagination has gotten more simple and flexible for 1.3. In 1.2 you could only use the built in Ajax pagination if you were using Prototype as your javascript library. With the addition of the JsHelper you can use any Javascript library that an engine has been implemented. My example today will be using mootools. I’ll be basing this, off of a freshly baked index view using the default core templates.

Drag resizing is a great interface interaction for web apps using panes, or window regions. Most Javascript libraries have convenient and simple methods to make drag-resizing a snap. However, what if you didn’t have a library at your disposal or were just interested in how to implement this interaction, just for the sake of knowing? Well I did just that when I implemented drag resizable panels for DebugKit 1.

While I’m a big fan of Mootools I work on a few projects using jQuery, and have recently been working on a project that needed a custom markup editor. I’m a big fan of the markItUp editor. Its a flexible and easily extensible editor, that affords a great deal of features in a small package.

Hopefully by now you’ve used DebugKit , and found it to be as useful as I do. If you’ve ever wanted to add a new panel, you can and its actually quite easy to do.

Events are the bread and butter of interactive websites. However, attaching and detaching events to the DOM can create memory leaks and performance issues due to time spent attaching events. This normally is not an issue, unless you are binding a large number of events.

If you’ve ever worked on a medium to large Ajax application, you know the headaches that Javascript can give you. On one hand you want to serve as few as possible Javascript files to users, but on the other you want to keep your sanity and work with lots of smaller files. This is where a build process comes in. It allows you to transform lots of files into one big file! You can even minify the big file for additional savings.

So much like the last one , this article is going to focus on a piece of the javascript language that I had trouble understanding, and may be a point of confusion for you. Today I’ll be looking at closures and lexical scoping. Last time, I mentioned that Javascript has more in common with functional languages, than classical languages.

My current work at CakeDC allows me to be on IRC a lot – like all day. And while I’m often quite silent during the day, I do scan through a few PHP related channels and I’ve noticed a trend of PHP developers who just don’t get Javascript. Either they don’t have the experience, or they do have experience and think its icky.