Tag Archives: javascript

jQuery UK 2015

I attended jQuery UK past week, sorry about the delay in writing about it :-)

The organisation was as smooth as it could be. They made sure we knew where, how and when to go to places and treated us really well, so it was a pleasure to be a speaker in this conference.

I must admit I was stupidly silly with regards to the conference at the very beginning. My programming bias elitism was yelling on my brain “oh I MIGHT NOT NEED jQUERY! Who needs it these days anyway!?”

But turns out that

  1. there’s lots of people who cannot afford to compromise on customer support, so they have to go the pragmatic way, and
  2. there’s a lot about newest web technologies we can share with them too!

So when they asked me to talk about Web Components I opted to frame it in the most pragmatic way too: how to use them without shooting yourself in the foot, so you can start working in a more modular way and taking in all those advantages.

I asked before starting and from an audience of… 300? 400 people? approximately 20 had heard about Web Components and about 10? had implemented them in a project. So I ran a quick introduction on what they were, why they were developed and how they looked like, before tackling them interoperating with the four main “frameworks”: jQuery, React, Ember and Angular.

A write up on the results of my research is upcoming, but in the meantime you can look at the slides if you’re so inclined. Be aware that something in Nightly was crashing with the slides at the time I presented, so if your browser crashes (including Nightly for Android)… you know why ;-)

The talks I watched:

Addy Osmani gave an excellent talk on the state of Chrome’s developer tools and then explained how their team identified performance issues on Wikipedia, and how to fix them (this was related to Paul Irish advising people to not to use jQuery’s hide() method). Also, Paul is sorry for tweeting that without the proper context.

Natasha Rooney explained what Service Workers were and what problems they were meant to solve, but I am afraid if you had not a bit of background it would be a little bit confusing as the topic is *complex*.

Andy Hume explained various techniques on how to deliver fast experiences specially on mobile.

Alex Sexton infused us with a bit of South-West American culture and told us about don’t mess with Texas, then tried to find an equivalent for the web (don’t mess for the web?) with regards to hacking/building websites that cannot be hacked.

Jenn Schiffer explained all about vart.institute* and how it came to be. Also provided multiple screenshots of Dave Methvin keynoting at various jQuery events, which was quite amusing. And invited us to feel more empathy for people in the industry, which is a good thing if you ask me. *you can read it as fart and feel silly and it would also be totally OK

Estelle Weyl gave a very interesting talk on how to use forms and take advantage of all the cool features that browsers are already providing us but some people opt to rewrite in clumsy ways that go against all accessibility and usability best practices.

Ben Foxall did one of his shows (at this point we should call those a performance rather than giving a talk) where he involved everyone on the audience and elevated our phones from mere “phones” to interactive objects or “things” that transcend the simplest notion of “phone”.

I’m sorry I couldn’t watch the rest of talks, but it was great to meet Alice Bartlett, Rosie Campbell, Anne-Gaelle Colom, Rich Harris, Philip Roberts, David Rousset, and of course, Bodil Stokke!

After the last talk finished, we moved to the larger ‘hall’ style space where there were some snacks and drinks and people could mingle and ask questions if they hadn’t had the chance yet, so that was way better for me than going to a crammed pub, as I could walk between groups and speak to different people and not YELL ALL THE TIME. There were also some stands and also RETRO GAMES but I started talking to people and forgot to check out the games. AAAAH! Funny moment: Mike MacCana getting super excited about how he could help them setup multiplayer in DOOM using IPX.

All in all a very interesting conference for people who build websites and are willing to improve their practices or tooling… or both! I definitely learnt a bunch of things, so highly recommend checking it out next year!

webpack vs browserify

I saw a project yesterday that was built using webpack, and I started to wonder what makes webpack better than Browserify? The website didn’t really explain to me, so I asked in Twitter because I was sure there would be a bunch of webpack experts ready to tell me—and I wasn’t wrong! ;-)


Webpack comes with “batteries included” and preconfigured, so you get more “out of the box”, it’s easier to get started, and the default outputs are really decent. Whereas with browserify you need to choose the modules you want to use, and essentially assemble the whole thing together: it’s slower to learn, but way more configurable.
Continue reading

The bumpy road to learning Ember.js

I’m doing some interoperability research lately and one of the things I’m investigating is Ember.js.

I had never used it before, but heard raving comments about it, so I guess I was expecting a smooth paved way lined with flowers and what not… and what I found was a lot of mental dissonances and mismatches between what I expected to find and what Ember wants me to do.

In the interests of reproducibility, this was my way of “learning Ember.js”:

On Ember’s website

I went to Ember’s website and clicked on /about. It just highlights separate features but doesn’t show me a complete one-page kind of quick start snippet. It also is pointing me to download a JS file which is weird to me as I might have got (badly used) to be able to npm install modern JS packages / libraries using npm.

To npm

So I opened npmjs.org in a new tab and searched for ‘ember’. The results seem odd to me. The ember package seems to be legit, as it has Yehuda Katz as one of the maintainers, but it’s at version 1.0.0-pre2 and was last published two years ago. Well, that doesn’t seem very useful. It’s probably missing functionalities compared to whatever the current documentation in their website mention, yet still people are downloading it: 1104 downloads last week, which might have got a bunch of them confused like me too. So…

… back to Ember’s website

I go back to Ember’s website, and click on Guides. Maybe I will find everything there!

I am greeted with a 30 minute screencast.

I am not sure if I can skip it without missing something essential–perhaps a note saying that it’s OK to head straight to the “getting started” section would be nice. And users can always go back to it if they want.

In the end, I decided not to watch it, because as a non native English speaker I find videos where I can’t see the speaker’s lips really hard to follow—I’d rather just read text, as there’s no risk of misunderstandings.

So I click on getting started on the left.

Getting started

The guide wants to show you how to rebuild TodoMVC. I am not interested in learning that, but I want to know how to get a basic Ember structure up and running, so I skim over the first two steps: Planning and Creating a mockup and jump to the third step titled Obtaining Ember and dependencies.

It enumerates dependencies and then tells me to add four script tags before the end of the body tag.

This is not even “sole fighting Ember’s convention over configuration” yet—it’s me thinking “this is 2015. I should be able to require() away instead of embedding script tags on a file, and what kind of manual dependency management is this?”

Searching away

Of course I won’t accept defeat this easily. Someone must have figured this out already! This is not an obscure library that someone wrote in a basement, right? I search around using various combinations of terms:

  • npm ember
  • gulp ember
  • browserify ember
  • require ember
  • … and etc

The results of my searches are mostly fruitless–I only find half baked attempts that “work kind of OK” for the person that posted them, but seem really fragile according to commenters.

A compromise with gulp-bower

I don’t know what it is in Ember’s architecture that makes it not play nice with Browserify, but I don’t want to fix it myself.

I keep reading and find this other section titled Getting Ember. It links to the builds section which is a page from where you can download JS files (not what I want) but it also says that you can install Ember with Bower.

It’s not ideal, but it can be scripted, which makes it better than manually downloading JS files, so I decide to opt for an intermediate solution in which I will sort of cave in and use Bower, but via gulp, using gulp-bower.

Of course in order to use Bower you better know which dependencies and which versions of the dependencies to use, so you can build a bower.json file that Bower/gulp-bower can read to install packages.

Ember’s website suggests using this:

    "name": "your-app",
    "dependencies": {
        "ember": "~1.6",
        "ember-data": "~1.0.0-beta.8"

I believe this is outdated (Ember is at 1.10, the builds page say). I adjust it as best as I can and run my magic gulp-bower sorcery. The packages are downloaded as expected, and I can reference them in my html, with script tags.

But what to include…?

I start by adding bower_components/ember/ember.js. A message in the console invites me to include ember.debug.js instead, which I do. A bit after I find that I might indeed need jQuery (#sorrynotsorry for the pun). I also find that I need to include a template engine thanks to another error message. None of these were mentioned on the section that refers to using Bower.

I remember to go back to the Getting Started guide and look for the bunch of script tags that I need to include:

<script src="js/libs/jquery-1.11.2.min.js"></script>
<script src="js/libs/handlebars-v1.3.0.js"></script>
<script src="js/libs/ember.js"></script>
<script src="js/libs/ember-data.js"></script>

I manually add the missing libraries to bower.json, change the script tags to use the actual bower_components/ paths my app is using, guess which script file it actually to use, and hope for the best.


It works! I can finally follow the actual tutorials!

Which I do, yet even if I’m feeling weird that they invite you to stick things on the Window global object:

window.Todos = Ember.Application.create();

Later I get stuck on the Modeling data section. It mentions some DS object which I have no idea where it comes from–perhaps DataSomething? I don’t know. The API page doesn’t show any module starting with a D.

So I skip that and jump to playing with components and templates. I find how to do two way binding, which is nice, when it works, and it’s good to find cases in which things do not work because that’s the point of my research. I also see the potential in using the MVC archetype, and the API seems reasonably readable…

But at this point, I’m really tired.

All this going back and forth for satisfying the minimum requirements could have been solved from the start if Ember used a dependency manager.

People tell me in Twitter that Ember wants you to use ember-cli to solve all these issues. But I don’t want to use their CLI: I like using my existing tools. Also, perhaps Twitter should not be the right place to learn about this. If Ember wants their users to use the CLI, it should probably be in the documentation.

In 2015, again, I assume that JS developers are good developer-citizens (developzens?), and will make it easy to compose different pieces together without interfering with other people’s setups.

Yet Ember feels a bit like this weird assembly of pieces and techniques of years past, and that makes adopting it into your existing workflow way more complex than it should be.


With thanks to Brittany Storoz for proofreading this post and making it way, way better than it would have been otherwise.

How to organise a WebGL event

I got asked this:

Going to organize a series of open, and free, events covering WebGL / Web API […]

We ended up opting for an educational workshop format. Knowing you have experience with WebGL, I’d like to ask you if you woudl support us in setting up the materials […]

In the interest of helping more people that might be wanting to start a WebGL group in their town, I’m posting the answer I gave them:

I think you’re putting too much faith on me

I first learnt maths and then OpenGL and then WebGL. I can’t possibly give you a step by step tutorial that mimics my learning process.

If you have no prior experience with WebGL, I suggest you either look for a (somewhat) local speaker and try to get them to give an introductory talk. Probably people that attend the event will be interested in WebGL already or will get interested after the talk.

Then just get someone from the audience excited about WebGL and have them give the next talk

If you can’t find any speaker, then you’ll need to become one, and for that you’ll need to document yourself. I can’t write a curriculum for you, as it will take way more time than I currently have. WebGL implies many things, from understanding JavaScript to understanding 3D geometry and maths, to how to set the whole system up and running on a browser.

Or can start by learning to use a library such as three.js and once you become acquainted with its fundamentals, start digging into “pure WebGL” if you want, for example writing your own custom shaders.

Or another thing you could do is get together a bunch of people interested in WebGL and try to follow along the tutorials on WebGL or the examples on three.js. So people can discuss aloud what they understand and what they don’t, and help and learn from each other.

I hope this helps you find your way around this incredibly vast subject! Good luck and have fun!

Now you know how to do this. Go and organise events! EASY!

It’s actually not easy.

Hashing passwords with Bcrypt and node.js

I have a little pet project that I’m using to learn Hapi.js.

Today I wanted to add authentication and since this is, as I said, a tiny little mini project, I want to only allow specific users (actually, just me) to log in, and not everyone+dog using bell or something of that sort. So I thought I’d go for hapi-auth-basic.

This module performs, not surprisingly, an HTTP basic authentication, and also wants a password hash generated with Bcrypt. I didn’t really find a command line thing that would generate the hash for me on this mac computer in a convenient fuss free way, and I also didn’t really spend hours looking because it’s Saturday, so in my most pragmatic move of today I decided I would just write a little snippet of code that would hash and verify the password using JavaScript.

So here it is, roughly based off this post of using Bcrypt with mongoose.
Continue reading