I started playing with service workers as a client side cache manager a bit tonight. I’m using this Smashing Magazine article as a guide. I’ve been reading a bit here and there about them, intrigued by their role in making web sites installable as apps and their ability to allow sites to function even while offline. However, my site’s current lack of pages and other priorities plus the learning curve and things that have to be done to set them up kept me from playing with them until now.
Workers require HTTPS, unless, luckily, you are serving from localhost. I had to modify my local app install to use that instead of the more site-indicative name it was using. They also require placement at or above the path level they apply to, or theoretically a Service-Worker-Allowed header, though I was unable to get that working. I’m assuming this is for some security reason. Because my file is stored in a Symfony bundle and because I am serving multiple sites with the same application, I didn’t want an actual file in my web root. I made a Symfony route and action that passes through the file, like:
What web developer’s site is complete without an easter egg? Until today, mine didn’t have one, but I had long wanted something. Since I was struggling to make forward progress on what I had actually wanted to work on this weekend, and had just been reminded of the Konami Code, I decided it was finally time to add one. I had seen a friend do a key sequence easter egg on a site he built a while back, which had put the idea in my head. The Konami Code sequence has been used on several websites already (Digg and Vogue are two examples I could get to work), so why not mine?
Recently, I made my first foray into the popular parallax on websites fad. My needs were simple: I needed to make background images move at a different rate than the content that sat on top of them when scrolling occurred. This was the first type of parallax I saw on the web and the most intriguing to me. I figured that there would be a lot of already built libraries to make this easy. Looking through the parallax libraries though, the most popular ones were quite complex or didn’t do what I wanted. I did find a couple of scripts that just handled the background image parallax, but I had some problems getting them working, and they didn’t work with vertically centered images.
In the end, I took ideas from those scripts and some articles to create my own parallax script. With my class library removed, the script would look like the following:
The heart of tmclasses is the create method. It is passed an argument with all of the configuration to create a class.
I’ve been doing quite a few responsive sites since I first started into them. I like doing them. They are fun to build, requiring new techniques and a different way of thinking to handle different situations. I like the concept and I like looking at the sites. One recent fun thing was dealing with an image map (on this page). Scaling the image and coordinates would be a pain and very expensive. An alternative option is to replace the image with a select drop down when the screen is too small for the image.
My most recent effort has been to bring in the use of Require JS. Require is an AMD implementation, which is an interesting extension of the module pattern. It takes the dependency injection part of the module pattern (ie passing variables the module will use as arguments into the function expression) a step further by handling auto loading of those modules with a script loader that will asynchronously load and run all dependencies for a module before running the dependent module, injecting the dependencies as either parameters or assigned variables. Require does this with names based on file path, sort of like a JS equivalent of PSR-0. Require also provides a build process that will combine all required module files into one and minify. I have not played with this yet, but am hoping it will take over my currently crappy build process.
So far, I’ve only converted over a small core part of my library, but I really like the direction it is going. The scoping/dependency wrappers around each module may add some bulk, but will also allow minification of all module dependencies and what not, so it may end up being insignificant in the build, especially since my current build process doesn’t involve much minification. Even if it ends up a bit larger than it could be, the development benefits outweigh that concern for me. It has also required a change in the way I construct my library pieces. The early pieces require being constructed in a certain order, and things don’t work as well when modules to depend on each other. But I think it will be really nice when I get the full library converted over and the build process figured out.