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!
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.
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."
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!
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!
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.
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
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.
"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.
"Gov.uk 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.
"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.
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!
When January arrives it's always time for New Year's resolutions - you know, those ones about quitting chocolate or taking up running that you realise a week later were not really a fun idea at all. I often hear people say things like: "Oh I don't make new year's resolutions because people just break them" or "I could do that anytime of year, January is a bad excuse!". Whilst I agree that if you want to do something, you should just start anytime, sometimes we need to help ourselves with a bit of a motivational kick and January - being a nice clean start to a new year, or at least feeling like one (even if it's technically just another day) can help.
I've seen "365" projects a few times before, sometimes photography, sometimes drawings, where you set yourself the challenge to create a little something on every day of the year. I generally don't like to dictate when or what I draw, as I find that never works out, maybe because I find it difficult to draw on demand and I just have to be in the right mood for creative pursuits. The typical pandalion thrives when enjoying a varied lifestyle with multiple hobbies, flitting between coding, doodling, and other creative or geeky pursuits, as well as playing far too many different videogames and not finishing many of them. I've always felt both in my personal and professional life, that I've never been quite content or good at focusing on just one "skill tree". There's just so many different fun things to do in the world! However sometimes the fact that there's so much I want to do and never enough time for it all, means that stuff I would like to do more of can fall by the wayside, purely from there not being enough hours in the day.
So, I decided to start a 365 doodles project in January of this year, with the aim of doodling something - anything - every day of the year. My hope was that I would motivate myself to exercise that drawing muscle more, giving myself smaller goals that would be easier to meet (it doesn't have to be a masterpiece! Just get something on paper). The main reason being that creating and putting something out into the world, as well as observing, consuming and passively taking things in, always feels like a great thing, regardless of what you create. Perfectionism is one of my most annoying traits and actually holds me back from creating things sometimes because of the fear that it might not be that good anyway, so again, this felt like a way to draw but say "hey, it doesn't have to be great."
I love videogames (what do you mean you didn't realise?? ;), and as a 29 year old woman, when I talk about this, I still often get reactions like "videogames are a waste of time", "I'm too busy for games now I'm older", "I create things these days, I can't just sit and play games". As I've said above, putting things out into the world is great, no matter how small that thing is, but I think it's missing the point if you don't appreciate the merit of enjoying the things that have already been created.
I've already written in some detail about how videogames are a fantastic blend of the creations of artists, artists in all kinds of fields - visuals, programming, storytelling, and music to name just a few. I really believe that inspiration is the beginning of all creativity. If you haven't experienced things that you enjoy, that have invoked emotion in you, how can you hope to invoke the same feeling in others through the things you create?
I don't have any technical training in drawing, and I don't see myself as a "serious artist", because for me it's really just something that comes from my heart. Everything I draw just comes from a picture in my mind that I think could be pretty cute, how it looks is some combination of the things that have inspired me over the years, the things I've seen and thought "ahhh that's adorable".
During my personal challenge to doodle daily, if I hadn't been doing much outside of doodling, if I hadn't experienced something recently that had brought me joy, it would be much more difficult for me to know what to draw, and I certainly had those days. But other days, I will have just been to see a superhero movie, or just played Borderlands for several hours and I would want to get those experiences on paper in my own little way.
I didn't get to doodle #365. I got to #176, and then stopped. I had a lot going on with work and moving house, but those weren't really the reasons, I guess I just wasn't enjoying it anymore, and it was feeling too forced. I felt like I was ready to stop, and wanted to go back to it not being a "chore", but picking up a pencil at random moments when I felt like it. And I'm glad I stopped when I felt like that too. It's part of the reason for me making this blog post - to explain the personal benefits of giving myself the project but also that not "meeting the goal" doesn't feel like a failure to me.
176 drawings is way more than I would have created had I not done this project. I feel like I exercised my "drawing muscle" and I helped myself create time in the day to not leave my hobby behind despite the other busy goings-on and responsibilities of life. I experimented over that time, tried different styles for drawing people, tried different characters or animals I had maybe not drawn before. I tried slightly different paper or techniques, I found what I liked or didn't like.
After that many drawings, I still don't feel like I "know" what I'm doing. I still feel like art comes to me on a whim, when I wake up on a Sunday morning with a picture of something cute in my mind and want to get it on paper. But, after I stopped drawing daily, I noticed that ideas would come to me, ways of drawing things would appear in my mind - inspiration from games or people or characters or situations - and my drawing muscle felt on better form.
So, what was the goal of 365 doodles? Obviously three hundred and sixty-five doodles, on one hand. But reaching that number for the very sake of it, I believe would have stopped me making some of what I think are "better" pieces later on, through letting that muscle have a rest. Though it helped and was nice to have friends watching my progress and cheering me on, the project was for my personal benefit - and do I feel like I've benefited? Yes, hugely. I'm happy that the project helped me devote time to this hobby, to try a lot of different little things and break out of my comfort zone a bit.
I'm happy that it resulted in being able to make a lot of my friends happy too, with doodles of their pets, favourite characters, or anthropomorphised versions of themselves. And when something like this happens - a photo of my friends beloved cats, which I turned to doodle form, and somebody else turned to a sculpture.. that for me just sums up how the joy of the things we love is the very thing that can spark inspiration, that carries on over different mediums, different people, and even generations.
So, to summarise - I didn't reach 365 doodles. But I don't feel like I've failed either. I got so much out of this personal project and to have been able to see others get some joy out of it too, that was awesome. Creation should be about enjoyment, as much as playing games or anything else we do should be, and it shouldn't be a chore.
So go forth, play games, read books, listen to music, watch shows, do whatever the heck brings you joy, and I'm pretty sure that joy might make you want to spread more of it in your own little way :)
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. :)
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!
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 :).
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.
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.
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!