Month: March 2017

AMP Gist Component

AMP Gist Component

Erwin Mombay wrote an excellent article on creating your first AMP Component.

AMP is a way to build pages for static content that render fast. AMP extensions use the power of custom elements and allows us to create new components to enhance AMP HTML pages.

While at the AMP Conference he showed us how to create one and that is what we did. We created the usual “Hello World” that was first featured in “The C Programming Language” by Kernighan and Ritchie (K&R). Admittedly it is a pretty boring thing to do, but it helps you grasp the structure and the logic of the app or language. In Erwin’s guide he shows us how to write tests and validation.

The AMP HTML repo has hundreds of issues open. They are nice enough to label some as GFI (Great First Issues) for people who want to start helping. One of those issues was to create a new component to display GitHub Gist so I asked if I could write it and they graciously accepted.

By writing this component, while it may be very basic, I have become more familiar with how AMP works. I believe that I’ve finished the amp-gist component yesterday. I created my pull request earlier this week and I got some good feedback. I had to make some changes, but they weren’t very difficult, and I made them. Then when it was reviewed, I had some more changes to make and some were more difficult. They offered to accept my pull request if I made some of the easier changes, but I wanted to try and make the more difficult changes. The way I was creating the iframe wasn’t optimal for performance and gave me some suggestions. So I’ve done some digging, looking, researching, thinking, and a little bit of trial / error. I believe I’ve got the more difficult changes licked. This component no longer qualifies as a GFI, according to the person who reviewed my PR.

It is my opinion, as well as others, that AMP HTML is the future of the mobile web. It could also be the future of a new desktop web. No one, not even Google, knows where this will end up. Even if the piece I’m working on is small; I am still excited to be part of this. I’ve always wanted to contribute to something that people may use on a global scale.

Node.js Package

Node.js Package

Encryption has interested me for as long as I can remember. I’ve been writing a decent amount of JavaScript lately, so I decided to try ricmoo/aes-js. It works really well and does everything I was hoping it would do. Since it does so much, the interface requires a little more knowledge than the average person may have. This is why I decided to write a wrapper for it.

Wrapper

My wrapper, disguise, provides a simpler interface to the aes-js library. I wrote my code in TypeScript and compiled it into JavaScript. It provides two simple methods that accept all the needed parameters to encrypt/decrypt messages. You must pass a password, IV, and a message; these are required to encrypt/decrypt a message.

There are also two static methods that instantiate the class and encrypt/decrypt the message. It currently uses the same IV for every call, but I’ll eventually fix that. So don’t use this for anything important.

Advanced Encryption Standard

The U.S. government uses AES for TOP SECRET information. Or at least they did at one time, I don’t think anyone really knows what they do. There have been side-channel attacks on AES, but in my opinion, those don’t count. An example of a side-channel attack would be watching someone type in their password.

Tests with Mocha

You should always test your code, well maybe not always, but if you want anyone else to use it then you should. I like looking at tests that other people write, because it gives me insight into their thought process. I don’t have much experience writing tests for JavaScript, so I did some peeking at other repositories. So I wrote some basic tests and it passes!

Conclusion

My wrapper simplifies the aes-js library. I can see why people like using JavaScript for the backend and frontend. If I decide to put this package on npm then I’ll link it on the resources page.

AMP Conf

AMP Conf

Last week I got to attend the AMP Conf in NYC thanks to Bulldog Creative Services. It was the first time they had a conference and I think it turned out awesome. I got into the city the day before the conference, checked into my hotel, ate some food, and then went to bed really early. The next day I get up early as I usually do and I end up being one of the first people there. Since I was so early I could pick any seat I wanted and I decided to pick one front and center. If you streamed it then you probably saw my head.

The conference was amazing The people were genuine, passionate, and kind. It was really neat to see a representative from Google, Cloudflare, Microsoft, and LinkedIn all on stage discussing how each can help AMP. The people working on AMP want feedback from everyone; they want anyone to help decide the fate of the project. I’m not a JavaScript expert, but I’ve decided to contribute by helping people with issues.

While in NYC I got to meet up with some friends and eat some delicious food. Black Tap Burgers & Beer had some pretty good burgers and an amazing milkshake. The line to get into Black Tap was wrapped around the corner. The next night my friend and I went to Nagomi Japanese restaurant. There were only two people in the place, but you still had to have reservations, luckily my friend did. The sushi was delicious. I couldn’t help but make funny faces of enjoyment while eating it and I think our waitress found them entertaining.

photo of New York City

AMP is the future of mobile websites and I’ll write more about it in another post. When I got back I decided to write some JavaScript and I created a playground for AMP HTML. I got the perfect domain for it as well, ampb.in, we’ll see if people actually use it.

TypeScript

TypeScript

TypeScript was created after JavaScript, but TypeScript is the parent of JavaScript. It is a little confusing, but it is similar to the what family members do in Kentucky, date their cousins.

TypeScript made JavaScript fun again (and better?). JS has been around for awhile, and it has taken some twists and turns to get to where it is today. JS and PHP have been battle tested and have emerged with a few bruises but have been victorious.

Anders Hejlsberg at Microsoft is a pretty smart dude. He was the lead architect for the team creating C#. He was also a core developer on the TypeScript project. I really like it for the fact that TypeScript adds optional class based object oriented programming to JavaScript.

There is also something called jQuery, and you’ve probably heard of it. It is a nice JavaScript library and one that I use frequently. It is rather simple to use and can speed up development time, but it can also be slower than “vanilla” JavaScript. jQuery is also extensively tested across the popular browsers, which is important.

Benefits

  • Object Oriented
  • ES6 (ECMAScript 6) support
  • Type-Checking
  • Client-side or Server-side apps
  • And more

Example

Below is some TypeScript that allows you to hide/show a specified element by a selector. TypeScript is then compiled into plain JavaScript. You can even change the compile options target to ES6.

TypeScript input


JavaScript output


Usage


jQuery Equivalent

It is simpler to do the same thing with jQuery, but is it better? The answer to that question is something you will need to decide. With jQuery, all you have to do is reference it in a script tag and then you have a whole bunch of functionality. Since jQuery has been around for awhile, it has been tested and enhanced. This allows you to use it and worry a little less about browser compatibility.

Example

The TypeScript/JavaScript example usage was modeled like the jQuery library. The code below is how you would do the same thing with jQuery.


Conclusion

I ran some tests even though I already knew plain JavaScript would be faster than jQuery. I then found out my tests on jsperf.com weren’t getting saved so I created my own test system. While creating my own test system, I learned a few things that I’ll share in another blog post. I put out a request on the internet for people to run the test for me, and I got a nice response. I didn’t record whether they were on a computer or using their phone. I only recorded the operations per second for each test. As I thought, JavaScript is faster than jQuery.

The test was run a total of 113 times. jQuery averaged 7045.635667 operations per second, and JavaScript averaged 169038.6408 operations per second. JavaScript is roughly 23.99196451 times faster than jQuery according to the results of this test.