Favourite CLI tools (which is really to say, what do I use all the time):

• nodemon - and yeah, I wrote it, but I wrote it because I needed it!
• tap
• z for zsh
• git - I'm still surprised when fellow devs tell me they use a GUI for git (though I don't know why I'm surprised)

Hmm, apparently not that much. I just ran history | awk '{ print $2 }' | sort | uniq -c | sort -n and it didn't reveal anything particularly interesting.

I have finished writing a book on the CLI which forced me to really learn the CLI again, and I actually have a nice (for me) collection of aliases and functions in my session, like these: .function examples.

Cool. :)

The reason I avoid build tools during development is very much tied to my workflow and ethic. With a transpiler in between me and my code, I can't live debug and change memory on the fly. I've written and recorded videos about this, and it generally boils down to my use of workspaces in Chrome devtools.

I know that you can use sourcemaps to see the original source code, but you can't interact with it as a sourcemap (in particular, you can't change it in real time).

So I've just gotten used to working like this. Also, as fun as ES6 is (the syntax changes), it's really just sugar, and I've been coding for nearly 20 years on the web now, so my fingers are pretty efficient at writing function, so it doesn't really cost me much.

But that is changing, and I can see it happening right before my eyes lately. This is entirely down to node@6 being out, and Chrome having a large part of ES6 natively available.

As for packaging, I think I've got the my workflow right now. I'll be writing about it in the coming weeks (or months), but it looks like this. Inside of travis (which will get each github push), it'll process all the code to ES5 using Babel, and that is tested, and that is released, but everything locally is written, tested and importantly, run using ES6 - without transpiling.

In reverse order:

Why is my twitter handle "rem"? It's my name. My first name is Remy, and only very close friends and family called me "Rem". But when I found twitter, I knew about the 140 character limitation and figured that registering with "rem" would save my friends a character.

Little did I know my IRL friends weren't on twitter, and this would only result in people (who I considered strangers) would call me Rem now. Initially it felt over familiar, and being British, over familiarity is a bad thing! However, I've since got over myself and it's kinda like anyone who calls me Rem is a friend. So now I have more friends.

For a while, the guy that had @remy (Dan Dickinson) got a bunch of the tweets intended for me during my public speaking, or when Introducing HTML5 was introduced (and apparently he'd get a lot of other misfired tweets) so he set up http://wrongremy.tumblr.com/ which was pretty funny. And then one day I met him! The internet eh?! :)

As for people that inspire me? That's a very, very long list these days. Initially I was pretty stupid about this, it was limited to handful of white guys (literally you could count them on a single hand), but as I've exposed myself to more people and more stories, I'm inspired by so many more people.

Pretty much everyone that's spoken at ffconf has been a huge inspiration for me in some way (here's the complete video playlist of the years we recorded), and a lot of the 350-odd people I follow on twitter - so check them out and follow them too.

(Sorry if that's non-specific!)

Thanks!

Other than sticking my phone in a Google Cardboard thingmegiggy, no. Looks interesting and I've had two separate CFPs sent for ffconf about VR on the web, so I'm definitely curious.

I never got there. I found Docker very difficult to get on with (without having previous container experience). I've since been back, and I can create the container, but I've not managed to understand how to use Docker Compose to connect together the parts.

A lot of the PRs suggested on github only factored for the personal install of jsbin, whereas I actually needed it for production, where I've got memcached, mysql and a host of other services connecting in.

So...one day.

That said, I do have the Docker beta app for the mac which removes all the weird setup required on the Mac, and it makes it a lot easier to work with Docker (which I've tried a few times to replicate bugs that I've seen in my Travis tests).

I don't tend to argue technology, if someone has hired me, they've hired my experience, and I don't intend to discuss my technical choices with the client.

But if you want a one liner: "PayPal use it in production. They get a lot of traffic. And they're a complicated app. How do we compare?"

¯\_(ツ)_/¯

I've been putting some work into https://confwall.com - which has been running at ffconf for 7 years now and I turned into a product at the start of last year.

It's made the money back from the development investment (which is nice) and I need to find time to market it to business.

I'm also intending to put out training videos, based around the workshops I do in person. I've got 3 topics in mind: CLI for beginners - to which there's a short book being published by A Book Apart in coming months, Node: full development workflow (from coding, full test coverage and deploying), and Debugging in the client.

I just need to find time...!

I'm fairly certain that when I built the first version of JS Bin I didn't know about github!

IIRC I was introduced to it as a place to host the jQuery interactive documentation (thing...) that I had updated (I've very hazy on this).

I've nearly always put my own code into the public (previously through direct links on my blog), so putting on github just seemed like the right place to put it. At the time, JS Bin was 2 PHP files.

But even today, all the payment logic is in github.

But great question. I'm pretty proud of that commit. I think sharing knowledge was the ultimate intent. It's the ethos of JS Bin too.

So...yeah. This is awkward... JS Bin is not written using React. Or Angular. Or Ember. I doubt if it ever will be too.

Mostly because I'm not personally interested, and as you said, when JS Bin launched there was no React. That was 8 years ago. I'm not sure that in 8 years that React will still be around (or maintained activity as it is now). Same goes for all the other frameworks.

I don't think Angular or React will win. I think something new will come along and knock them out of the conversation (again, Backbone is still around, but it's no longer top of the crop).

Also, I'm an old dog, it's hard to train us old dogs 😉

I don't and I don't. I mentioned in another question that I don't use Babel (or indeed any transpiler) during development, so I don't personally see these problems (which sorta sucks for other people).

But it's definitely worth duplicating your issue on github, there's other people answering questions on nodemon, and possibly have encountered what you're seeing.

The PWA stack really excites me. Service Workers and the like take the "extensible web" approach, which, for me, gets us back to thinking about a progressive web (rather than relying on JavaScript up front).

I'm also seeing ES6 land in a lot more environments which is letting me start to adopt more of the ES6 sugar because I've always preferred my workflow to be "build-free" (and obviously I then need to build to push to production).

Overall: it's looking good! (...I think)

I'm writing Node.js exclusively these days. Even the bits of client side JS is actually backend Node being tweaked to work in the browser.

As for productivity hacks: get rid of build steps, reduce test times, complain about stuff that doesn't work, don't accept crap.

I'm going to be publishing a blog post on semantic release (which is super awesome if you don't already use it) and another post on my development flow in Node, which again is without a build process. Basically: code to node@6.

I prefer (and by prefer, I mean "exclusively use") smaller modules and libraries over frameworks. But that's first because my work allows for it (and I'm picky about my work), but also because I'm not super keen on high abstractions and being dictated to by a framework :)

Hey Kai, you're welcome by the way :)

1. jQuery lasting for another years: absolutely.

   Why? Because it's got such a low barrier to entry for developers to start doing any DOM stuff, and the documentation and community around is ahead of anything out there. It may not be as advanced as the fancy frameworks, but it's extremely accessible to new people coming to the industry.

2. Favourite HTML5 API... hmm. HTML5 specifically, or in the "umbrella HTML5". So, assuming strictly HTML5, I guess...the History API - it fixed a lot of interactions that ajax broke.

   If you mean more the umbrella term of "new Browser APIs" - I think the media APIs are pretty neat (of course there's all the APIs that go under PWA...but this is like a toy box that I can't chose the coolest thing!).

3. Tech: my client work focuses exclusively on node at the moment, partly around CLI but I tend to also break my work out into standalone modules (which means CLI has to support 0.10 and upwards, but the standalone stuff can be node 6).

   I've just recently also started using Babel and ES6 (I know right, who knew?), but I'm not using Babel during the development, so there's no watch+build step.

   Otherwise, it's node, tap for tests, travis and that's about it. I tend to work quite close to the metal.

If your question is: have I checked out webpackbin...then I have now...

If you're asking about multiple tabs/files in jsbin, you wouldn't be the first to ask. There's a technical constraint that means it's not simple, but there's also just not enough justification to drive the development. I'm pretty sure there's an open issue discussing it, but I don't have it to hand.

So, first up: me personally (and all the projects I've worked on), I don't use ReactJS, Polymer or etclib. So I don't have any of that baggage (though I've got all the vanilla JavaScript baggage instead!).

I do tend to use Less on projects though, and ideally I would create component files for each "section", but honestly it's not really something I've had to do. Either because my projects are small when I've done all the CSS myself (i.e. my blog), or someone else will produce the CSS, and they've already broken it up into logical sections.

I think separate smaller files always makes sense no matter what you're doing, it's easier to consume, debug and test.

Hey Davor - four questions in one, eh? 😄

I will admit that I've not done any large client side projects in a while (my client work has been for 9 months, and I've been focused very much on the server side).

1. Architecture.

   Honestly, I don't think I have a good structure for this right now. I've got a good workflow for node projects, and structure, but client side I'm not so sure. JS Bin has a rough category of directories in the js folder, and then everything is "supposed" to be a small module. But the downside is that it's all cat'ed together, so there's variables that leak from one script to another.

   I love the require system that node offers, but I don't like what require.js forces me to write. I don't use transpilers, so that means I don't use browserify (though I know this has an excellent rep).

   Maybe using ES6 import will be the way I go, but until it lands natively in at least one browser (hopefully Chrome since that's where I enjoy working).

   Not a great answer, sorry!

2. BEM

   We're using BEM on the current client project, but I don't personally use it. I've read how it's supposed to work, and it does make a lot of sense, but (as I mentioned in another answer) because I don't use it day to day, it doesn't stick in my head.

   However, the output from using BEM has impressed me so I'm likely to try to learn how it fits together.

3. How do I learn

   Generally I skip, and I mean super-super light skim of a blog post or two. Typically looking for the source code, copying and pasting and seeing if it works. If it doesn't, I might abandon. If the source is too complex (like WebGL!) I tend to attempt a tutorial but quickly abort.

   I definitely learn through trial and error. I've bought a load of books over the years, but in practise, I'll only read a few pages.

   I do reach out to Chrome devrel with questions though, and it's their job to help developers, and Jake Archibald in particular has been extremely helpful in replying and helping me grok concepts like promises (from earlier years) and service workers.

4. Where do I apply those skills

   Pretty much anywhere I can. I'm not good at inventing problems to apply new tech to, but if I have an existing problem, I'll go to work on it.

   That can range from writing C for my Pebble so that I can stop my Toggl timer from my watch, to learning about Selenium so that the client I work with can run full functional tests.

You're going to love this answer...probably...possibly not: I literally have no opinion! I don't even know if there's a new thing called modules or if you mean the thing that I'd easily confuse with CSS4 (which, yes, I've been told, isn't a thing)!

So, yeah…it's cool?

Hey Tristan (namesake of my brother!). JS Bin was definitely a work of love at one point, and I believe will be again, but I definitely prefer bouncing between projects. I keeps my tools sharp.

Right now I've been doing a lot of node development particularly for the CLI and I've learnt tonnes about testing and streamlined workflows (which I'm intending to create into a video series - which, is another one of those projects).

So really: I like to juggle my work as much as I can afford to.

Hi Larry - glad to hear of a fan of jsbin :)

I'm not really thinking about the future of JS Bin at the moment (or this year certainly), only because I'm very heads down on client work at the moment.

The things I would like to do with JS Bin don't really add new features, but it includes:

1. Complete rewrite of the front end
2. Complete rewrite of the back end (specifically splitting out the API and re-using that internally)
3. Adding service workers for offline support (which is already in a branch and decent way through)
4. Make Docker some part of the release process
5. Getting npm version back in lock-step with the version on git

The problem with all these things is that it doesn't increase the paying users, which means that it's new functionality that I'd have to build during "business hours" and not be earning...which is hard to justify after 2014's experiment of doing JS Bin full time.

Utterly aside, if you don't have a sticker (since you're a fan), you should totally request one: http://jsbin.com/help/stickers 😉

Hi Ida,

Generally I prefer lightweight CSS frameworks, but I'm not normally the one doing the implementation. Someone on the teams I work with has already selected one, and I tend to refer to the docs as to how I'm supposed to style a button or a list or some element.

I'm not hugely keen on the frameworks that look like every other site (jQuery UI suffered from this in the past), but on the flip side of that, I do like the Material Design (and tend towards Material Lite if I'm working from scratch).

As for personally recommending, it depends on the problem. If you're prototyping, then definitely use whatever's quickest. Keep it simple if possible and try not to get too locked in to any framework.

Glad to be here!

Hmm. Flexbox. So, honestly, I lost track of the differences in the implementations of Flexbox. I do remember the time that Firefox had one implementation and other browsers had another and it was a bit of a faff to get it right, but those days seemed to have long passed.

Honestly though, I know I want to use Flexbox a lot more, but I always get burnt on the syntax (and I rarely get it to flex the way I want first time around). It's because I don't use it day-to-day (like I do JavaScript), most of the CSS I write, I'll write and then move on and forget about it.

So, to answer: yes, but ¯\_(ツ)_/¯