Tag Archives: javascript

On Loop 2015

I was invited to join a panel about Open Source and Music in Loop, an slightly unusual (for my “standards”) event. It wasn’t a conference per se, although there were talks. Most of the sessions were panels and workshops, there were very little “individual” talk tracks. Lots of demos, unusual hardware to play with in the hall, relaxed atmosphere, and very little commercialism—really cool!

Continue reading On Loop 2015

Some additional thoughts on the recent discussion about “frameworks vs vanilla JS” on mobile

Some context for those of you that haven’t been following this thing:

Paul talked about his research on whether to use a JavaScript framework on mobile devices was good or not, for a number of parameters of what “good” could mean. I thought it was a really good starting point because it is nuanced, has data, considers a number of pros and cons and it’s, in short, way more constructive than the usual FRAMEWORKS SUCK message.

The conclusion is that vanilla JS is faster to start as it doesn’t have to do all the bootstrapping that frameworks do. But perhaps using a framework can also be convenient for you as a developer—and for the user if the developer can provide value to them instead of building their own ad-hoc framework. But ultimately the decision depends of each particular case, and each developer has to make their own judgment.

Unfortunately people in Twitter started essentially responding that “hey phones would just get faster (MOORE’S LAW!!! MOORE’S LAW!!!!), so deal with it and use a framework”, and by the way, “actually Paul used an old version of Ember and also React would never be used that way”, despite the fact that Paul said so himself in the post. Anyway…

Tom didn’t quite like the analysis and said that you would need to compare using some other app other than TodoMVC because it’s too simple.

Dave added some more insights too, replying to Tom.

I want to add a number of additional reflections because I ALSO HAVE OPINIONS and since I’m done with talks for the year, I have time to manifest my thoughts now:

The “phones will get faster” fallacy

They might. But that’s not the case for everyone who is not a developer or a techie. The constant, absurd, terrifying-to-witness delusion of developers who believe that everyone is accessing their websites using a 4G connection with the latest and greatest device is just painnnnnful.

Granted, some apps will be built for very niche segments, and you can “count” that they will have the appropriate device to run those. An example of this, somehow, could be games that only run on PS4. The crucial difference is that, ideologically and ideally, the web is not a closed controlled platform as a games console is, despite the multiple and insistent efforts from certain vendors and the irrational buy-in from many developers.

But I go on the streets and I do not see everyone using the latest and greatest iPhone. I see a variety of devices. Tons of cheap Android phones which are suuuuper painful to see in action because the hardware is ‘utilitarian’ but developers assume that everyone has a great Nexus phone as they have. And also—people have been taught that they have to install an app per service because said services do not know how to build a website to provide the service. So turns out that people do need to complete a lot of tasks with their phone, and the more apps they install, the more crippled the phones become.

Yes, you can get another phone which is faster, but it’s going to eventually get slow as you reinstall your ‘task based’ apps again. And the fact that is “faster” doesn’t mean that it actually is giving you the 100% of the resources to you.

Also: apparently JS is not getting faster on Android, despite people buying ‘faster’ phones.

Todo MVC might be, in fact, good enough

While it might not be a super complex app, it is still an app and something we can compare between different ways of offering the same functionality built in different ways. Dismissing it because it’s smaller is ignoring the fact that this is a low bound of “how bad” it gets even with small apps. If anything, it might get even worse.

Code size is not necessarily bad by default

You can have a big code base that seems to run very fast on the phone—time from download to render being super small and the app being very responsive.

But you could also have a very small code base that blocks like there’s no tomorrow, and makes the users of an app cry in frustration because it makes them think that their phone is somehow broken (“WHY IS THIS SO SLOW argh I’ll need to get a new phone OMG NO”).

The sweet spot

Or: but what do you really need?

Framework fans often seem to get offended that the simple proposition of not using a framework (also known as “vanilla JS”) is brought into a conversation. “WHY WOULD YOU NOT WANT TO USE A FRAMEWORK IN YOUR SITE?!! ROWR ROWR ROWR GROOOOWL!!

Well, actually, you might not need a framework. Or maybe you might need one. Or maybe not now, but soon. So it’s good to plan a little bit ahead, but it is not advisable to plan too far away, because you might be adding lots of additional baggage you won’t need after all.

I think that using a framework starts to make sense once you go past a certain level of complexity. Specially when you have URLs that need to be parsed with a router, and then you have to render templates and all that—possibly your best bet is to use an existing framework with a good community behind, so that people have already tried doing similar things to what you might want to do, and there’s lots of literature you can find.

Those are probably well better tested than any “Frankenstein framework” you might write, and can also offer you great features such as rendering on both the server and the client side, so you get the best of both worlds. Developing this kind of thing yourself might take you a very long time.

But maybe you don’t need to do all that; perhaps you just need a router. Or just a template engine. In my ideal world you should be able to just pick bits and pieces individually, and use them. But that tends to only work for small projects.

Frameworks as a neutral option

It’s not explicitly discussed in the existing posts, but adopting an external framework developed, vettoed and regulated by some other organisation can be one of the most neutral things to do in organisations which do not want developers to “get territorial”, i.e. if the whole organisation adopts the framework ONE of its developers wrote, that developer “wins”, and it creates a potentially problematic power dynamic. I guess that would be Conway’s law at its best.

Another great side effect of not using a framework developed ‘in-house’ is that developers who work on the code base later don’t need to deal with the terrible lack of documentation that is the usual case with in-house frameworks. To date I yet have to see an in-house framework that is not terribadly documented, and I’ve been building stuff for the web for more than 15 years…

Developers love to engage in loud neverending discussions about framework technicalities but it’s important to keep in mind that politics are what ends up driving adoption more often.

History repeeeaaaating

I already wrote about libraries and frameworks back in 2007, where it was assumed that you had to choose a PHP framework. Ah, this never gets old…

Same conclusions apply, so I’m just going to literally quote myself:

[…] investigate […]


“An introduction to Web Components” at Manchester Geek Nights

I was in Manchester last week for a Manchester Geek Night meetup organised by ThoughtWorks North. I gave an overview about Web Components, and potential issues regarding accessibility / SEO, and using them with some of the popular frameworks:

Slides: onlinesource code.

It’s kind of similar to my jQuery UK talk, but updated, because many things have changed since March.

Yet people in the audience are mostly still not using Web Components or don’t plan to do so for the time being. They are mostly happy with the UI options provided by their framework of choice, or what they do doesn’t really justify the investment that Web Components require.

I am however hopeful that browser vendors have finally agreed on something and things are starting to move towards a minimal, commonly agreed with, implementation of something-web-component.

But I am going to politely decline doing talks about Web Components until the tech is a bit more stable. I am not working actively with UI/Web Components stuff at the moment so preparing these talks requires a huge investment of time (as I don’t like telling lies, or lies by accident).

Possible futures, and nodebotting

You might remember that I was sorting out my music collection. This involves having to use iTunes for adding cover art and editing metadata and blah blah because I’m using a Mac and it seems that everyone has given up on making anything (anything!) better than iTunes.

So iTunes is this big huge mass of software that attempts to do everything at the same time and does nothing particularly well, and we’re all using it because there’s not much more else available. Talk about user choice, wooops.

Yesterday I was realising this horrible situation and started a parade of tweets:

  • I never know whether to cry at the immense UI failure that iTunes is or just laugh at it so ironically being the flagship product at Apple
  • When using iTunes I’m afraid to click on buttons because I do not know what havoc will that unravel. Things move around without explanation
  • There are buttons that turn into something else, something elses that act like buttons, data losses, weirdnesses, ugh
  • The worst is: there doesn’t seem to be anything better in Mac? (!?) 😭PLEASE PROVE ME WRONG, I BEG YOU 😭

Someone suggested Vox, which I haven’t tried yet. But seriously–only one suggestion! is that all that there is? I ended up thinking again about writing my own “player”. Except it would not be a player, or at least, not just a player, but I was thinking more about a sort of jukebox with sync. Of course I have other things to do right now so that’s probably not going to happen unless I win the lottery I don’t play.

I was in a good mood this morning so I decided to pretend I was funny and laugh at this whole mess with another tweet parade:

  • the year is 2030.
    you can do grocery shopping, pay council tax, vote for your fav eurovision artist and resolve git conflicts with iTunes
  • in 2045 iTunes finally gains sentience and writes the code for you. all commit messages mention titles of U2 songs
  • 2525 it is revealed that iTunes has acquired Skynet (to the tune of Visage’s In the Year 2525 but poignantly sung by Bono)
  • 3001: Frank Poole begs to be killed again by HAL 9000 when he sees iSkynet in action

And instead of sitting back and maliciously grin at the idea of this actually happening and how 2030 is in fact quite close in time and I could be saying “I told you so” in only 15 years, I grabbed my bike to go to Tableflip, the home of Nodebots in London, for a lighterweight NodeBots day.

Good things: it was a gorgeous day (specially compared to yesterday’s where it poured with rain for about 90% of the time), and I got lost in Dulwich which is a beautiful, albeit very adhoc and non-grid at all area, so it’s even a pleasure to get lost and wander around those streets.

Bad things: there was nothing bad about getting lost because there was absolutely no rush at any point during the day.

Oli was a fantastic host and he made us bacon sarnies and coffee. Their space is a-ma-zing. It’s full of tools old and new, and equipment and things and dust from sawing and weird mechanical and chemical smells, and flying things in various sizes and shapes, and there’s some other business where someone is building bikes. BIKES!!! It’s all super cool and I came back very excited about making stuff, even if I just managed to sort of use Johnny Five to control a servo:

Meanwhile, Tom was hacking on his Maschina and making it emit various sounds with JavaScript, Alex was transferring PCB positives onto another surface using an electric iron and two other guys were doing fantastic hacky stuff as well. I also got to hear about Fritzing and it looks really good.

I’m glad I got to use part of the equipment in the Spark core kit I got at JSConf.US 2014 which I still hadn’t had time to use. I’m sad I didn’t get to use the Spark core itself because the nodeschool nodebots workshop is designed for Arduinos and I wanted to see something happen physically and not just emulated, but I am certain I’ll be able to research this before iTunes can also talk to Spark devices via iPay or whatever.

Playing with hardware is fun. I am an almost total newbie in this field. I keep forgetting which pin is the N pin for LEDs (it’s the short one, I just looked it up today). I keep forgetting how to read resistors and how to connect things together. It’s all fine: it’s on the internets, somewhere, or alternatively it comes back to me once I get started. I have absolutely no expectations for what I’ll do and so I can’t let myself down if I forget everything from the last time I played with hardware. It’s OK. It’s a game. It’s fine to forget the rules, you can always re-read them.

And if you haven’t had enough future scenarios, here’s also this very funny article: A horror story that starts with Twitter.

npmoffline: installing npm packages from the cache

npm has a feature where you can ask it to install packages from the cache, where cache-min forces npm to avoid installing packages younger than that value:

npm --cache-min 9999999 install <package-name>

This works, but I’m never going to remember that syntax, so I added an alias to my .bashrc file:

alias npmoffline="npm --cache-min 9999999 "

So now when I’m offline on a plane and want to install a package that I’ve already installed in the past (and so I know is in the cache), I can write this:

npmoffline install <package-I-already-installed>

and it will pull the contents from my cache.

Yayyy 🎉

If it doesn’t work you can also list the contents of the cache with

npm cache ls

and see what packages and versions have been cached. Perhaps you can also grep it, to discard the packages you’re not interested in, e.g. the following will only list entries related to node-firefox:

npm cache ls | grep node-firefox