Fronteers 2014 - part 2

Oct. 23, 2014, 8:41 p.m. in Web Design


Hello! Welcome to the second part of my blog posts about Fronteers 2014 - a front-end web development conference held in Amsterdam at the start of October.

My last entry focused on some of the user experience and user consideration talks that really resonated with me. For this entry I want to talk about some of the other cool stuff I learnt at Fronteers, with an emphasis on web animation, and I want to begin with one very awesome lady!

me and rachel nabors
Rachel and I in Rotterdam! I'm the slightly shorter nerd. XD

If there's anyone in the web development world I've always been a bit of a fangirl of, it's Rachel Nabors, an awesome lady who started her career as a comic book artist, before becoming a front-end web developer. I find it's somewhat more common these days to find front-end web developers who come from a programming led background, or are heavily interested in Javascript as their main "thing", but less common to find those of us who maybe come from more visual/designery/arty backgrounds. Even though there is so much new and awesome Javascript stuff (uhh, "stuff" is a technical term :P), MVC frameworks and whatnot these days, I still personally believe that there's a lot of room in front-end development for the more visual-led of us.

As doodling is one of my favourite hobbies, I love when I can find ways to incorporate art or cute character designs into web development. With my affinity to visual media on the web, I've always been a fan of the idea of CSS animation - not least because I love how lightweight, maintainable, and device-agnostic it is, but also because of how it's a lovely way to combine art and code, and a new way to provide more visual goodness to our websites and applications.

Anyway, I was super happy that as well as getting the chance to meet and hang out with Rachel during my Amsterdam trip, I also got to attend her CSS animation workshop, and hear her speak at Fronteers. As I say - I have always been a fan of CSS animation, and this little codepen - Mr. CSS lion - is so far one of the few things I've played around with that combines my drawing style with CSS (worth mentioning because Rachel's work heavily inspired this!).

That was a while ago, and there haven't been too many animation challenges for me at work recently, even though we do get the opportunity when working on interactive ipad edetails to use animation to liven up an otherwise static presentation. Rachel's talk reignited my hope that some more of those challenges come along in the future! These are a couple of my favourite things that she talked about to help us with CSS animation:

  • Steps! - Even though I've done CSS animation quite a bit, I didn't know about these for some reason. Steps are a cool way to split up stages of an animation without having to add loads of extra points to your keyframes. One super cool use for this, is if you have a sprite of various images that may make up an animation (eg a walking animation or maybe a logo animation or whatnot), you can use steps to tell the animation how many states to have without manually setting all of those states. Say you have 5 sprite images in a file, you could set the starting background position, and the end background position and tell the animation via steps, how many in between states there are. Rachel demonstrates this better than I can explain here. But anyway, I wasn't aware of this previously and would have previously added more percentage values for different states, so this seems like a really handy way to handle certain animations, especially if you want to animate sprites.
  • animationend - and other handy javascript events that get fired through CSS animation (there is also animationstart and animationiteration). These events give us a nice way to control and also link our CSS animations to each other, for example firing one when another has finished. We could also trigger the animationstart event when hovering over a logo for example. One of my main issues with CSS animation in the past has been controlling a large number of them and keeping them maintainable and not too dependant on every other part of the animation. I've often tended to string delays together (for example the first part starts at 0.5s, the second animation starts at 1.5s), but this means that making changes somewhere in the middle of the chain can really confuse things. I like the idea of combining these animation events, along with some simple jQuery, perhaps manipulating classes too, to make animations more modular and able to be amended at different points more easily.

Anyway, my attempt to explain the coolness of CSS animation in text may not make a huge amount of sense, but make sure to check out some of Rachel's codepens for more examples - this walking cat one combines steps and animation events and is a simple but cool example of some of the possibilities we have with CSS animation now.

Is this useful for my client?

Obviously animating drawings is cool and fun, but does CSS animation have a place in our day-to-day jobs and client work in various industries? I think it absolutely does, and Rachel actually drew a lot of attention to the benefits of CSS animation when it comes to improving how users interact with our interfaces. I liked this quote below that she included, alongside an example of a typical dropdown menu, and how the shift in states, whilst obvious to some of us (the younger or more tech-savvy), it can be harder for other users to make that connection, and small animations and transitions can really help with that.

“By offloading interpretation of changes to the perceptual system, animation allows the user to continue thinking about the task domain, with no need to shift contexts to the interface domain. By eliminating sudden visual changes, animation lessens the chance that the user is surprised.” E. Hudson and John T. Stasko (1993)

I know that Rachel sees the web as much more than static documents - as a canvas with so many possibilities! I think CSS animation and transitions can be used subtly to bring static things to life, or can be used to guide our users around certain bits of our interface and help them see what's going on. And even if some of our users are on old versions of Internet Explorer - we can make these animations more of an enhancement for the users with modern browsers, and degrade gracefully for others.

Rachel rightfully pointed out that CSS animation and transitions shouldn't be something we attempt to tack on at the end of a project, as an afterthought, but rather that we should think about how we design our sites with these possibilities in mind. I definitely would like to see interaction design making more use of CSS animation because I think it gives us some great new options for interface design.

The Google Material Design documentation has some great responsive interaction examples of how animation can help our users.

SMIL-e... more animation! :)

Going nicely hand in hand with Rachel's workshop and talk, Sara Soueidan gave a wonderfully information-packed talk on animating SVGs using CSS and SMIL (Synchronized Multimedia Integration Language if you want to know!). SVG animation gives us a few extra nice options for more advanced animation with SVG shapes, for example if we want to animate more advanced graphics, have them scalable and still be able to use CSS on them. One thing that's cool alone is that:

"Basically, any transformation or transition animation that can be applied to an HTML element can also be applied to an SVG element." Sara Soueidan

But not only that, SVG animation gives us even more options than CSS animation in some cases! Using the <animate> element within an SVG, we can tell it things like how to animate, and even how to start animating (e.g. "begin = click"). I especially like that you can do things like "begin=click + 1s" to start an animation a certain time after an element is clicked.

Another really nice thing is that you can chain animations by doing things like setting one element to start animating a certain amount of time after another has started (or stopped). SMIL has many more properties that let us do some really cool animation functions without much code, and I think the possibilities for these on scalable graphics is awesome. Animations along SVG paths are another cool thing. There are so many cool things to know about these, and Sara is an incredible font of knowledge, which her talk showed! I recommend reading her guide on CSS Tricks to learn more, and there are some great examples in her fronteers slides also.

As for support, SMIL is widely supported - well... with the exception of all Internet Explorer browsers. :P But since we could use modernizr to check for SMIL support and provide fallbacks, or have this as an enhancement for all the other browsers that DO support it, it still seems like a pretty good time to think about trying some of this stuff out!

Infrastructure FTW

I realise I've written quite a lot about animation alone.. you can probably tell that it's one of my favourite areas of front-end development! I'm going to more briefly mention the other talks purely because this entry could go on forever.. (you can have a cookie if you're still reading :)

Daniel Espeset talked about the role of frontend infrastructure at Etsy, with a focus on the importance of having continuous deployment and letting "anybody touch anything", which I liked. At Incuna we generally have front-end as well as back-end developers being able to deploy sites to staging after they've worked on them and it's super useful I think to have all developers being able to do that. Daniel talked about tools like "Ranger" and "Builda" that Etsy built themselves for tracking deploys and code, and also discussed how the team had moved to using Scss for more maintainable CSS. At Incuna we use Sass and I would never go back now - the usefulness of CSS preprocessors such as these is amazing. Read Daniel's slides.

Nicolas Gallagher from Twitter gave a somewhat similar talk, about Twitter UI infrastructure. I liked that his talk focused on making the infrastructure as reusable as possible, allowing people to "spend time on creative things" instead of having to spend a lot of time on infrastructure everytime they work on a new project. This is something we've worked on a lot in the past couple of years at Incuna (and I have to give Perry Roper a mention for initiating a lot of those changes such as incuna-sass). We factored all of the CSS that we kept reusing in projects into our own Sass component library so that we can use it on projects every time and not spend time rewriting things. It's super useful!

Some of the other advice I found useful from Nicolas:

  • Have a shared language between design and engineering teams.
    I think this is something we can get better at!
  • Design for adaptability, not perfection.
    Use components to help people work on different parts of a larger app without effecting others.
  • Consistency is the best option.
    Make it so that anybody in a team can pick something up and work on it.
  • Make skilful use of what is at hand.
  • Documentation and ownership over institutional knowledge.
  • Hide complexity of infrastructure from developers
    and allow the infrastructure code to be changeable without effecting the dev's existing work. (This is another thing we're doing quite successfully with an edetail library that we use as a base for interactive ipad edetails)
  • Create habits among engineering teams

A round up of the rest

Dave Olsen gave a great talk on optimising web performance. He pointed out some of the perils of responsive web design that only considers layout - where we end up downloading too many elements on mobile by over-using "display: none". He recommended some useful tools, such as:

and of course if you're not already using chrome dev tools, the network and timeline are always super useful!

I also like that Dave Olsen discussed how you would get performance measuring into a client's budget or into your project workflow. He recommended having a "performance budget" and aiming to beat a baseline - for example, decide that your page speed score will be 25 percent lower than your nearest competitor. I think this was an interesting way to try and justify why it's worth spending time on webpage performance and also have something to aim for rather than a hard to measure goal like "make it perform better".

Fronteers featured some cool mini sessions on gaming in the browser. Being a massive videogame fan I always think I should try and make a game and never get round to it. Phaser sounds like a very interesting framework for HTML5 games.. if i can ever get round to stop playing them to make one! ;)

Forgive me if I've not mentioned all of the Fronteers speakers in my blogs, I've focused on those that are most relatable to my personal interests and role in front-end development. There were some talks on WebRTC, but they were a bit more technical and went over my head a little. XD (or was it that big lunch...? ^_^) I'm sure they were very useful for some other attendees! Anyway, here are all the slides from the conference if you would like to catch up more on anything I've mentioned or some of the other talks!

Collection of Fronteers slides

All in all, Fronteers was a wonderful conference to attend (not least because I love the city of Amsterdam!) - it reignited my enthusiasm for CSS animation (and grew it for SVGs!), it reminded me that Incuna are on a pretty good track with our increasingly modular and consistent codebase, and it also made me see the areas we can improve on when it comes to user needs and really merging our design and front-end practises more which is something I really hope we might be able to do more in future.

A more fluid, dynamic web

I've written before about how closely I see the link between web design and development, and how the canvas should be the browser, and I think it's true more than ever these days. With the different devices we are working with, and the animation and interface possibilities - the pure fluidity and changeability of the web, design isn't the static thing it may have once been. Some of us still have fairly waterfall processes in our companies, but I really hope we can all try and combine our design and front-end development processes much more closely because I really think that we are working towards the same important goal - what the user sees, uses, and interacts with, and making that a more useful, easy, and pleasurable experience.

Thanks for reading! :)

Fronteers 2014 - part 1

Oct. 14, 2014, 9:17 p.m. in Web Design


Last week I attended Fronteers 2014, one of Europe's largest front-end web development conferences, in Amsterdam. It is the third web conference I have ever attended and my first time attending Fronteers, and it was a great experience!

Before I talk about what I got out of the conference, I just want to say that I was really impressed with the organisation of Fronteers, the atmosphere, and approachability of the staff in particular. I was pleased to read and hear that they had a code of conduct, and thought the way that the staff drew attention to it, and were always on hand to talk to at any time during the event, made it feel like a safe and inclusive environment, which is super important! :)

This is going to be a two-part blog entry, focusing on the main learnings I took from the conference. For the second part, I'll talk about some of the more technical talks (including CSS animation and game making, yay!) but for this first part, I'm going to focus on one the over-arching messages from the conference, which I think one of the speakers, Petro Salema, summed up best:

"The goal of technical innovation is user experience" Petro Salema - #fronteers14

Web development has really come on in recent years, and being a front-end developer these days encompasses a lot more than it used to. From designing layouts, creating html, adding a bit of Javascript, and uploading our code via FTP, these days front-end development involves much more. Knowing version control such as git, CSS frameworks like Sass, as well as all manner of Javascript frameworks and libraries for all sorts of things that they web gives us power to do. New libraries are cropping up all the time, and technically - we're doing great! We're in a more knowledgable, powerful place than ever with all manner of tools to help us out. But in this transition, in this "best practise" focused environment that we're currently in, have we forgotten some of the basics of the days when we called ourselves "web designers", and coding was a smaller part of what we did?

Heydon Pickering kicked off Fronteers with a talk that discussed just this, questioning how much our obsession with "best practise" is actually relevant to the user, and whether it improves the product as a whole, or how much of it we are doing to maintain our own developer standards - are we sometimes obsessing over the wrong things for the wrong reasons?

"A front-end developer asks 'How should I do this?'. A designer asks 'Should I do this?'" Heydon Pickering - #fronteers14

So often we focus on "best practises", but UX - "user experience" - is still an afterthought. UX is the kind of thing we want to pay somebody to come in afterwards and check, or that we think about at the end. Maybe we see it as a separate role.

Heydon's message was one I feel strongly about myself - that as developers, we all need to start thinking more in terms of design. About why we're doing things, if we should be doing them, and realising that user experience should fall into our role as much as knowing technologies should. It's great to be striving for good code practises, but maybe we should be striving to get a user experience focus higher on our radar again.

Heydon's slides - "Getting nowhere with CSS best practices"

"We are all web designers because
we are all contributing" Somebody at #fronteers14.. sorry, my notes failed me

Design products for less than perfect situations

This was another strong message coming from the conference, which goes hand in hand with a larger consideration of user experience. Alex Feyerke's talk, Offline first drew attention to just how many apps are treating offline as an error, rather than the default state being that the user may have no (or no decent) connection. He talked about how his library Hoodie treats offline as a default and strives to ensure that a user can get to their data when they need it, and not just when they happened to have a connection. Personally I have experience of both being annoyed that I can't use an app offline, and also developing an app where we think "oh yeah, we should put in an error if the user has no connection", so it was useful to shift our thinking back to a user's default state being less than perfect.

Alex's slides - "Offline first"

Walk in somebody else's shoes

" stopped asking what departments want to say, and instead asked what citizens want to know." Meri Williams - #fronteers14

Meri Williams talked about the importance of accessibility and how we need to try and "bake it in" to our workflow, so that it doesn't get forgotten. We may often think that somebody with a disability or accessibility challenges is a minority, but just by talking to your family or somebody you know, we can find out that the use case for our product goes way beyond us, in our offices with our large mac screens and fast connections. It was interesting to be reminded that around 8% of users have difficulty lifting or grasping a mouse for example, a percentage that is almost equal to or higher than some of the percentages we try and include when we schedule in Internet Explorer development. Too often accessibility is an afterthought, or an "extra cost" but Meri rightly pointed out how vital it is to start considering how different people in different situations are using our products and how integral this should be to our process.

Meri's slides - "Baking in accessibility"

"We need to find a way to walk in somebody else's shoes, & see what's different for them." Meri Williams - #fronteers14

Know your accessibility bias

To finish off this first part, I'll return to Petro Salema, whose quote I used earlier. His closing talk "Dream big, think small" on day 2 of Fronteers, opened in a rather harrowing, post-apocalyptic way. He told us a story of planes returning from war, with bullet holes in the wings. The engineers would take that to mean that those parts of the plane needed more work on protecting them from the bullets, and would focus on fixing that area of the plane. What they failed to realise, and what one person eventually realised, is that the opposite was actually true. The planes that returned could withhold the bullets, and so they came back - the ones that couldn't, never came back.

" You can't get a better answer than the question you can ask, limited by your experience" Petro Salema - #fronteers14

Petro's tale, and the rest of his talk, was an eye-opener on how much our own "accessiblity bias" dictates the questions we ask, and the problems we solve. We want to think big, and solve big problems, but we need to remember to "think small", to not simply design ideal solutions to ideal problems, but to increasingly consider the smaller things that take place, the things users may be doing that we haven't even thought about - simply because of our own bias. As he discussed - we can't help our experiences, and we can't help that they naturally effect the questions we ask and answers we come up with, but it shows the need, ever more, to try and find the smaller questions, so we don't miss out on solving the smaller problems that we're not even looking at.

Panda thoughts

I think that, as resonating as these talks were, and as important as the messages were, it's often going to be a challenge in a commercial client world to get some of these considerations to the forefront. Many of us still work in "waterfall" type processes, and don't always have access or resources to get as much user feedback as we would like. Following the conference, I returned to work, feeling like it was wrong that we're all developing in Chrome, seeing our websites 90% of the time in their "best case scenario". However, I then tried to do some development in an Internet Explorer virtual machine again and.. I remembered why we don't develop there by default. XD Even so, I really do think it's time to get user experience back into the limelight again, as much as coding practises are to front-end developers, and find ways to put ourselves in other situations more when we're using the products we develop. I think UX is the responsibility of everybody, and it's going to take some thinking to see how we can get this into our workflow. Thoughts, or comments, or anything I have got incorrect above, appreciated. :)

Part two, where I will talk about some exciting web animation stuff, and some bits and pieces from the other talks at Fronteers, coming soon!

Incuna at jQuery UK 2013 - part 2

April 23, 2013, 1:15 p.m. in Web Design

White October cupcake
Amazing cupcakes from White October

This continues on from my first post - Incuna at jQuery UK 2013 - part 1, I wanted to finish up discussing a few of the other talks from the day and what I took away from them. :)

Following on from where I left off, the final talk before lunch was Douglas Neiner talking about Machina.js, a framework for Finite State Machines in Javascript. I’ll be honest, I’d never heard of a “Finite State Machine” before, so at first I was worried it was going to be something over my head. But not at all, and this was one of my favourite talks because of the clear and concise way it was presented. The basic idea was that Machina.js provides a cleaner way to deal with situations where your code may otherwise end up with a nest of if/else statements. I’m quite a visual person, and I think I find it easier to understand certain bits of code or concepts if I can see how they would be applied to a real situation. So, I definitely felt engaged in the talk when Doug provided some interesting, visual, real-world demos, the main example being a router. As well as being a great, simple example of what Machina.js was actually doing and how it can help you manage those different states, it was also a great example of some lovely CSS transitions/animations and attractive front-end work (something I’m a big fan of :) I’m not sure of any exact situations we may want to use this right now at Incuna, but it’s definitely something I’ll remember thanks to the excellent talk and demo.

After lunch (which included the delicious cupcake above!), Garann Means gave a talk on using events to glue full-stack frameworks together. Unfortunately I didn’t have a good view for this talk and couldn’t see the code examples very well and the rest went over my head a little :( Following her talk, my Incunauts and I did take a look at Marionette, the library she was using for Backbone, as we use Backbone in our projects at Incuna. So I’m interested to learn about that a bit more, also because the website is so pretty.. (there I go with the visual stuff again! :)

The next talk was Ilya Grigorik and was entitled “Wait, Chrome Devtools can do that?”. This was probably the most useful of the talks for me in terms of concrete information that I knew I could go away and look into, and hopefully use to improve some of our workflow processes and testing/debugging. The main thing to take from the talk is download Chrome Canary now! I hadn’t realised how far ahead Chrome Canary was in terms of the devtools, so that was useful to know. He also talked about some really useful and interesting features such as:

  • Better use of the timeline, including saving timeline traces as HAR files so others can recreate it, to see where something is loading slowly for example.
  • How frames per second apply to webpages as well as games, and how slow paints or costly CSS effects can affect this and cause (as Chrome puts it) “jank”, and how you can use the devtools to diagnose this.
  • How if you change CSS in devtools, Canary can actually give you a diff of your changes (yay)
  • How you can add custom panels to Devtools, the ones that sounded particularly interesting of these were jQuery Debugger and PageSpeed Insights. One of the coolest things mentioned about PageSpeed Insights was that it would suggest compressing an image for further reduction and at the same time offer you a download of that image at the reduced size! Oooh..

Finally, it was very useful to hear that Canary has remote debugging, for Android at least, with the ability to use all the same DevTools features whilst debugging on the device. Remote debugging is something we sometimes still have issues with at Incuna, so anything we can do to improve this process is great. There was a lot more useful information, you can read it in Ilya’s slides, there’s also a super useful Chrome Devtools course on Code School and it was interesting to hear about a weekly Chrome Youtube show The Breakpoint.

After Ilya, John Bender gave a talk about faster DOM manipulation with category theory, and he had some great slides, but it was admittedly a little maths-heavy for me. So, uh, moving on..!

I enjoyed the final two talks - it was interesting to hear Joe Petterson talking about his experience of still having to develop for older versions of IE, also as it the talk was around a pharmaceutical site, similar to the things we work on at Incuna. He gave some good thoughts on using IE VMs for testing (which we currently do), but also how you might use Selenium or an external service like Saucelabs to be able to test accurately on the VMs. Front-end testing is still something we need to do more of and look into more at Incuna, so this felt pretty relevant to recent work conversations.

Finally Jason Scott from Blackberry talked about building “an experience, not just another framework”. I was interested to hear a talk from this perspective, as ultimately, the reason we’re all writing jQuery, and the end point of all of our sites and apps is the user. He talked about using jQuery Mobile and customising the theme for your user. This was quite familiar to me, having used jQuery Mobile a few times at Incuna when working on Phonegap mobile applications, and I found myself agreeing when he pointed out how it doesn’t make sense to try and replicate all native functionality with things that just don’t work as well in a webview - for example transitions that require a a heavy amount of rendering. He also mentioned Grunt JS as a build tool for minifying and uglifying files. We have scripts for doing this on our projects at Incuna but it still sounds like it could be a useful thing to look into.

Overall, it was a great day with a really interesting range of content and it was nice to meet some new people in the jQuery community. It definitely left me feeling inspired. Yay!

Incuna at jQuery UK 2013 - part 1

April 20, 2013, 4:21 p.m. in Web Design

Incuna front-end
The jabberwocky was meant to be in the photo, oops

Yesterday my fellow front-end Incunauts and I attended the jQuery UK conference in the lovely city of Oxford (where we are lucky enough to work everyday of course!). White October put on a fantastic Alice in Wonderland themed event complete with jabberwocky t-shirts, jam tarts and even white rabbit pawprints to follow to the location of the event.

It was a great day - socialising with the community, listening to some brilliant talks, and enjoying maybe slightly too much of one of my favourite games of all time - Micro Machines! - in the amazing retro gaming area provided by Replay Events (who I’d never heard of before but now I want them for my birthday party :).

I wanted to get down some of my thoughts on the talks - what I took from them personally (as a front-end developer who’s using jQuery but still working on her fundamental/advanced Javascript understanding), and the ways in which the Incunauts might be able to use some of the new knowledge and advice. I’m going to write this in 2 parts since it got pretty long!

The talks started with the creator of Javascript, Brendan Eich discussing some of the upcoming features of ECMAScript 6. For me, being someone who (as I mentioned above), still has a fairly long way to go with Javascript itself, I can’t say I fully understood all of the code examples that Brendan showed and discussed. But nevertheless, it was interesting to get some background on the JS development that is still going on. The highlight of the talk for me was probably the live example of Unreal Engine 3 (the games engine that runs games like Mass Effect and Gears of war) running in the browser using only Javascript and WebGL. Although I’m very much an "armchair gamer" these days it was very cool to see how far these things have come, and that the possibility to have these kind of games running in a browser is there.

Richard Worth, the director of the jQuery foundation then gave us an overview of the recently released jQuery 2.0, which drops support for IE6,7, and 8 but allows a smaller, faster library for environments where the IE support isn’t needed (or where the code jQuery needs to support IE could actually cause problems). At Incuna we still do often need to support IE8 and on occasions 7, and I think some people (myself included) may have initially thought “this is well and good dropping IE support, but my clients still use IE, don’t I get to use 2.0??” However, jQuery are still continuing to release 1.x versions and have promised that the API will be the same as 2.0 - just without the IE support.

So what I took from this, is that jQuery 2.0 is just another option or branch of jQuery for now - a better option for when you’re doing stuff that you know won’t be used on IE. For us at Incuna I think this will be great to use for when we’re doing things like Phonegap/Cordova apps, allowing us to use a more minimal version of the library without all the unrequired code. But for our websites that need to support IE7/8, we can continue to use 1.9 and 1.x as it gets released, as for the foreseeable future jQuery aren’t getting rid of it, and we’ll be able to use the same API.

A little interesting fact from Richard was that over 50% of websites use jQuery - and actually over 90% of websites with Javascript use jQuery! That's pretty awesome and shows that jQuery is pretty much the go-to library for working with the DOM in Javascript.

Remy Sharp’s talk was, interestingly, about why we shouldn’t always use jQuery. At first I was a bit like, “ahh, this is a jQuery conference, why are you saying use less jQuery, write more Javascript??”. But reading his blog post following the talk, I can see that his point was to not just turn to jQuery by default, and throw the library in as soon as you want to add some Javascript. He pointed out that there are indeed a good number of things that can easily be done with Javascript alone, such as getting the value of an element with .value instead of using the jQuery .val, getting attributes from an element, or simply adding a class. He also mentioned querySelectorAll as a way to select elements from the document without needing jQuery.

I can certainly see why he advises not to just “throw in jQuery” when some of these things can be done simply with Javascript and it’s definitely something I would consider more in the future. However I think the requirements of the project still need to be considered a lot - if you need to support older browsers and the inconsistencies that jQuery deals with in this case, and also if using jQuery is going to allow you to, as the tagline goes, “write less” and “do more”. I think that as much as there is no need to look for jQuery equivalents to things that can be done simply in Javascript, there is equally no need to feel like we should need to write tons of extra Javascript for something that jQuery might deal with well and allow us to spend less time on. In some parts of his talk I did almost get the feeling that he was saying “write more, because if you can do it with Javascript, you should”. But perhaps that’s not what he intended to say, more that we should just consider more if we really need to use it.

Richard Worth mentioned earlier that jQuery is modular now, and if you all you need to do is some document manipulation, you can leave out the rest, making the gzipped version just 10k. Considering the size of an average jpg on our website, I don’t think that the size of jQuery in many cases should be a worry if we do want to use it. But again, I think the whole jQuery vs. Javascript should be considered on the requirements for what you’re trying to do at the time, your project and your client. Overall though, for me coming from the "jQuery first" angle, the talk was definitely helpful to be reminded of/introduced to cases where writing Javascript is almost as simple as writing jQuery and might make more sense.

It was interesting that Remy’s talk was followed by Adam Sontag, whose talk was titled “jQuery is a swiss army knife (and that’s ok!)”. I think Adam’s talk was my favourite of the day, for subject but also his speaking style and the way he discussed the subject. As I tweeted yesterday, it was like a “big warm jquery hug” :) He talked about the way in which jQuery is a multitool/swiss army knife, it has all these parts we can use - and they are there to help us build something, as a tool should. We shouldn’t only use it, but also, it’s there to assist us, so there’s really no reason to dismiss it because it’s a library and think we should build a house with our bare hands for some reason. I think he really strongly disputed the criticism of jQuery and how silly a lot of it is - we’re often blaming a tool for what people do with it. Someone could use a knife to craft something amazing or to stab themselves in the eye - either way, it’s not the tool’s fault, there’s always going to be a spectrum of users, and that’s okay.

Maybe somebody doesn’t fully understand Javascript and is using jQuery, and if that helps them to get things done - great! Not everyone may go from that to try or even want to understand the Javascript behind it, but for others it will give them an entry point and maybe inspire them to learn what’s behind that and make programming more fun. For Adam himself, jQuery was his “gateway drug” into Javascript, and I feel very similarly myself. Adam also mentioned this article - jQuery made me a programmer by Oscar Godson - which I found myself relating to a lot. When you’re not from a programming background it can be tough to learn Javascript from text-heavy programming books. jQuery can show what code can do, make it more exciting and easier to get into, which for people who want to learn Javascript can then provide an easier way to understand what’s going on behind it. We should help and encourage people to learn, and not dismiss or make fun of them for using jQuery as their pathway into programming, if that helps and inspires them.

Adam also gave some useful tips on caching jQuery selections and backed up Remy’s point of not wasting time looking for jQuery equivalents for things you can do in JS. But what I really took from Adam’s talk was renewed inspiration for my own Javascript understanding and the feeling that it’s okay to still be learning, and to learn from jQuery. My favourite quote from him was “Relationships that go beyond code improve code”. This is so true. Different things inspire me personally to want to code and improve my coding - they are things like videogames, visual things, cute things, all the little things that inspire me in life - but one of the main things is people and good relationships, particularly the people I work with everyday at Incuna. Our little front-end team, in particular, is pretty close-knit - we get on great, hang out outside of work sometimes, talk on twitter a lot, and most importantly we support each other and learn from each other when it comes to coding. Our team is a big inspiration to me to keep improving and I guess my point is that no matter the code you learn, it’s super important to have those relationships around that support you and help you improve :)

I’ll leave this here for now, but will discuss the other talks a bit in my next entry along with some useful links that I took away from the conference :) Thanks for reading, and feel free to share your thoughts/comments!