Web development isn’t fun anymore. It used to be that you picked a server-side language, typed up some human-readable HTML, sprinkled it with a little bit of JavaScript to improve the user experience, and your job was done. These days it has become an all-you-can-eat buffet of overlapping frameworks, many of which don’t play nicely together, which you are almost blackmailed into using in order to fix problems or deal with a particular web browser, that is, if you’re not lucky enough to use something like Ext JS which takes care of all these hassles.

This past couple of weeks I’ve had to research using web components for a new project. “Keep calm and #UseThePlatform” it says on their web site. So what are they?

Web components are a set of web platform APIs that allow you to create new custom, reusable, encapsulated HTML tags to use in web pages and web apps. Custom components and widgets build on the Web Component standards, will work across modern browsers, and can be used with any JavaScript library or framework that works with HTML.

Sounds promising. Web components are not like your dime-a-dozen widget library and are supposed to be the future of user interfaces on the web. So I read some more and pretty soon it becomes clear that Polymer is probably the right way to go. Somewhere along the way I came across somebody who said that Polymer is to Web Components what jQuery is to JavaScript. It basically makes it easier to write Web Components and cuts down on all of the boilerplate code you have to write; that’s all I need to know.

The use case that I was given involves a simple web service call to search for records and display them in a grid. Easy. I’ve been doing that kind of stuff for almost two decades now, so this shouldn’t be much trouble at all. By a country mile, the only grid worth using if you want to create a custom element (another term for these things which means that I’m creating my own, reusable HTML tag, such as <my-awesome-tag>) is the one from Vaadin. This blog post is already becoming a rambling mess, so I’ll cut to the chase here and say that I couldn’t get version 2 of their grid to work with my Polymer 2 custom element, so I had to install version 3.0.0-beta1 (which works perfectly fine except that it hangs Internet Explorer 11 if you tab into the grid; I can see that beta1 has been pulled and only the 3.0.0-alpha2 version is available again, maybe because of this bug?). No biggie, they’re bound to fix it eventually which shouldn’t stop me from continuing my research.

Within a few days I created a magical web component which fired a custom event when the user selects a row (so that anybody who uses <my-awesome-tag> can add an event listener to handle it). I also set up data binding between my element and an input box which automatically sends requests to my web service whenever the query parameter changes, thereby updating the grid with new records seamlessly. Wonderful! Web Components really are the future of the web. There’s only one problem – I use Chrome as my web browser because it’s the fastest (especially when it comes to testing apps heavily dependant on JavaScript, such as Ext JS). Does it work in Internet Explorer 11?

No. All this time I had been coding away happily in a version of JavaScript that this nearly four-year-old browser does not understand. Just great! Polymer 2 uses the sixth edition of JavaScript, variously known as ECMAScript 2015 or ES6 [read this if you’re really bored]. If you want to use Polymer 2 components in IE 11 you have to transpile ES6 down to ES5 and serve up the former only to newer browsers (Firefox, Chrome, and Edge 14+) and the latter to all versions of IE and earlier versions of Edge. Yay! I get to experience the delights of browser sniffing (you could just serve the ES5 transpiled bundle to all browsers, including Chrome which supports Web Components natively, but you would need to include the custom-elements-es5-adapter.js shim, which just seems nasty; I’d rather do browser sniffing so that Chrome can fly and only IE suffers).

After getting that sorted, I turn my attention to getting this custom element to work from within an Angular app. You could do entire apps in Polymer but that would require a bit more work and Angular had already been chosen as the other framework for this new project anyway (not by me). So I start learning and find that Angular and Polymer both are projects by developers at Google with a lot of similarity, but one is playing the short game and the other a long game. Angular does its own thing whereas Polymer tries to adhere to standards (or specifications which eventually will become standards and supported by all browsers one day).

As I type this rant at home on a Friday night I’m trying to recall the arduous journey I’ve taken this week so that I can fully document the experience for everyone’s amusement. I can’t recall the finer details of the problems I had trying to get my Polymer 2 component to work with Angular 2, but my console was full of indecipherable errors and I soon realised that the two don’t play nicely together; I would need some assistance from @codebakery/origami and would have to upgrade to Angular 4. I suppose I should have started taking notes by this time because the journey was truly becoming tragic, but I couldn’t get Origami to work either, and my search for some other options came up empty handed. I decided to admit defeat and declare that I could not get Web Components to work with Angular.

If I was asked to evaluate Web Components specifically instead of any other widget library then there must have been a good reason, and my research lead me to the view that they might just be the holy grail of user interfaces on the web, so maybe Angular was the problem? I soon found this excellent summary of a talk by Rob Eisenberg comparing AngularJS, Angular 2, Aurelia, Ember, Polymer and React. Rob once worked at Google on Angular but eventually left over disagreements about the direction it was taking (and after my brief exposure, I began to see why: it’s over-engineered and would lock you in to using Angular for everything). The recommendation at the end piqued my interest in Aurelia: it doesn’t get in your way, supports web components, high performance, clean syntax (Angular 2 is just ridiculous!), standards compliant, and great if you’re a good developer.

I saw mention of Aurelia in some tech news article once but dismissed it out of hand, thinking to myself “yeah, yeah, another framework… yawn”. The Quick Start guide is probably one of the best such articles I’ve ever seen and the more detailed tutorial did not disappoint. The page describing its Technical Benefits seemed to tick all the boxes, too. I proposed to my colleagues that we should abandon Angular and use Aurelia instead, and after a little hesitation, they went along with it.

Another day, another framework to learn. Never mind, this one finally does seem like it’s worth my time, so I got stuck in and had a good time learning it. I then try to integrate my Polymer component with it and after a few issues (mainly surrounding me learning a new framework; nothing is ever easy!) it seems to play nicely enough. I was surprised that it seemed to “just work”. Great. Time to test it in Internet Explorer 11. Computer says no and I even served up the ES5 version just to keep it happy. I didn’t realise straight away that Aurelia even had a seemingly well documented article on Integrating Polymer components which I didn’t notice originally (there was a lot of stuff on the Internet, albeit slightly out of date, asking about Aurelia/Polymer integration which suggested it wasn’t officially supported yet, so that was my bad for not thoroughly browsing the docs).

My project directory already had about 120MB in my node_modules and bower_components directories from using npm and bower, but in order to get Polymer to work with Aurelia I had to also start using JSPM. This added another 50MB to my project, thank you very much! I have to call System.import(‘aurelia-bootstrapper’) after the WebComponentsReady event, but my project was created using the Aurelia CLI meaning that my app is started with a simple script tag pointing to scripts/vendor-bundle.js and wasn’t using the System.import method. My attempts to load the vendor-bundle that way didn’t work and when I tried to create a link element in vanilla JavaScript and append it to the DOM myself after the WebComponentsReady event had fired, I got a blank page in my browser and no errors at all. Well, that’s just great. Aurelia should update that Polymer integration document to explain how to kick-start your app if you’re using a production build and not the System.import quick start method.

By this stage the day was getting on and it being Friday, I thought, “enough is enough”. I don’t need this shit. Aurelia is nice and all, but I shouldn’t have to subject myself to this much torture just because Internet Explorer 11 has to be the default browser because of some shitty, over-priced, corporate application which only works if IE is set as the default browser, and of course, asking people to go into IE only for that shitty app and to use Chrome or Firefox for everything else just won’t do, now, will it?!

Sadly, this is what web development has become today:

Being a web developer in 2017 and having to support Internet Explorer 11 is like a chef having to go dumpster diving for food to cook and being forced to serve it in a dog bowl.

I really don’t care any more. Let’s just use Angular for everything and be done with it. We can’t have nice things if people insist on using a web browser that’s almost four years old.

I’ve had the kind of week that only chocolate and ice cream can fix, and maybe binge watching a new TV series, too; I still haven’t watched the latest seasons of Fargo or Better Call Saul. That sounds like a plan to make everything better :-)

My brother has been on my case to blog something about web development; he blogs at the drop of a hat whereas my offerings are usually spread years apart. I develop using Ext JS for a living (among other things) and its lack of a combined date/time field is very annoying. Previously I would copy the time onto the selected date before saving the record, but that’s a bit nasty. So I’ve written some ViewModel formulae to do it instantly.

Here is the result:

Specifying the date first will default to 9:00 AM, and specifying a time first (without having entered a date already) will default to the current day. I am using the ViewModel.links property to create a new DateAndTime model instance (which I’ve named ‘rec’). The Date and Time fields are bound to ‘{Date}’ and ‘{Time}’ and the get and set methods on their respective formulae take care of changing the shared datetime field on the model. There is a display field bound to the ‘{DateAndTime}’ formula which shows the current value the moment it changes.

It’s quite likely that anybody not versed in the many intricacies of Ext JS won’t have a clue what I’m talking about here. This post is not for you :-) But it might help some poor sod dealing with the inconvenience of not having one field to take care of both the date and the time in Ext JS. Perhaps an override might be better but I try to come up with solutions that don’t involve any extra jiggery pokery (I also use Sencha Architect, where it’s very easy to see what I’ve done if I happen to work on my old code one day; it does happen from time to time!).

So, it’s been almost two years since I posted anything here, and it’s just over two years (almost to the day), since I last had a good whinge about XCode. It has only been laziness that has kept me from spewing much guts here about all kinds of annoyances.

So, I’ve been learning Swift for the past year, and whilst it was long overdue, it’s only the language part of the equation. The Cocoa API is still a nasty piece of work; give me the .NET Framework and C# ANY DAY (except if that means I have to use Windows at home; sorry, but I can use it at work writing web services and such like, but I’m not letting that operating system near my computer at home).

So, here’s what drove me mad about XCode/Swift/Cocoa today:

I used to have a drag/drop connection between a combobox and a class to handle the selection change event. That worked fine, however, when I modified it to also handle updating something as the user typed each letter in the combobox, the handling of selection changes failed. You can only handle one or the other when doing the drag/drop connection crap between the combobox and the IBAction.

So, I found a delegate method, which means that I modified the relevant view controller to implement the NSComboBoxDelegate protocol so that it suddenly receives all of the methods in that protocol, whether I implement them or not; the ones I care to implement actually do get called, and the others are ignored. This seems strange to a .NET programmer, and takes a bit of getting used to, but it can also be very powerful (and a time saver in some cases).

This delegate method is the comboBoxSelectionDidChange notification. Being a “did change” event you’d think that it would only call the method when I have actually finished selecting an item from the drop-down list portion of the combobox. You would be mistaken. Past tense apparently isn’t past tense in Cocoa.

Only one problem: if I use “combo.stringValue” inside that method it still returns the previous value in the text part of the combobox. If I want to get the text of the item that the user selected, I’ve got to do this:

My first iPhone app was made available on the iTunes Store today: a Cribbage Calculator. I’ve been playing cribbage with my next-door neighbour for almost a year now and sometimes you come across a hand with so many combinations that it’s rather challenging to add up.

So, in order to learn Objective-C (which is quite a shock for someone used to languages with “normal” syntax, such as Perl, JavaScript, C#) I decided to write an app to help me calculate complex Cribbage hands. I can also see what the app publishing process is all about, too.

If you’re too lazy to add up those 24 and 29 hands (even some 12’s and 16’s!), then this app might be for you. It might also come in handy if, say, you’ve imbibed a few glasses of port while playing cards :-)

This post is called Self Flagellation with Objective-C and XCode because I think that is an apt description of what I’m doing. In case you don’t know what flagellation is, this wikipedia article will provide the full story, but suffice it to say that it comes from Latin and means whipping, and that’s exactly what I’m doing to myself every time I try to use XCode.

I should probably number my grievances because there are probably going to be many, and they’re not in any particular order. I should also point out that it’s early days for me with XCode, but after buying several ebooks on Objective-C and Mac/iOS development, and reading two so far and doing all the exercises therein, I’ve had more than just a cursory glance at XCode, and I feel as though I’ve given it quite some time for it to prove its worth before giving up and curling up into a ball, crying like a baby (which is an appealing prospect at the moment!).

XCode is full of annoying control-dragging of things to other things, for example, simply in order to wire up an event for a button or an outlet for same if you want to be able to talk to said button programmatically.

Clicking on a file to work on it overlaps the previous file you had in the main editor area in the middle. If you double-click on the file, it opens in an entirely separate window, not in a tab as one might expect of anynormalIDE. You can open files in a new tab, providing you open the new tab first, then click on the other file you want to open in that new tab. There is no right-clicking on said file to open in a new tab, that would be too useful!

This is more to do with Objective-C than XCode but all classes are really split across two files, the header file (.h) and the implementation file (.m). As someone who is used to storing everything for one class in a whatever.cs file in my day job, having to toggle between .h and .m at home is a major pain. The logic (as far as I can tell) is that the .h describes the public interface that other objects get to see, and you could theoretically let the world see these .h files without giving away your trade secrets, which are kept safely hidden in the .m files. Maybe this makes sense to people who are in the business of writing third-party libraries or open source developers, but I don’t care about all that; I simply want to have one god-damned file for the lot, but it seems it’s a very bad idea to try to do this anyway. Having to switch between these two all the time is just a major pain in the you-know-what!

As someone how was brought up with Windows 95 to Windows XP then various Linux distributions for the roughly five years to December 2012, I’ve come to consider certain keys on my keyboard as being “normal”. For example, pressing the Home button jumps the cursor to be beginning of the line. Not so on a Mac, it goes to the beginning of the entire document! How many times do you think somebody might want to start typing at the beginning of the document? No much, hey! Anyway, XCode does let you map the Home key to move to the beginning of the line (unlike the rest of Mac OS X, unfortunately), however it does exactly what it says, moves to the beginning of the entire line, and not to the first actual character of code after the white space used to indent your code properly. This is just another one of those things that makes me wonder whether anybody at Apple actually uses XCode, and that perhaps they’ve got some secret in-house IDE they keep to themselves because when I press the Home key, I expect it to go to the beginning of the “if” statement or whatever it is. I’m sure any other normal developer who might read this would expect the same behaviour, also. Thankfully, I found the XCode4_beginning_of_line plugin on github that corrects this shocking oversight on Apple’s part.

Just tonight I tried to debug some code (for the first time), and after remapping the “step over” key from F6 to F10 (I’m so used to the Visual Studio key that I cannot change this old habit!), I discovered that stepping over code doesn’t always mean step over in XCode. It quite often means “step into a massive page of assembly code”, which, I’m sure you might agree, isn’t particularly useful, especially if you’re like me and don’t know squat about assembly! Here’s a picture showing what I’m talking about, and no, I’m not using a release configuration. There’s also a Show Disassembly When Debugging option which I do not have ticked, either. Encountering this major annoyance is what prompted me to write this blog posting, so perhaps I’ll find the answer tomorrow, but for now, I’ve tried the obvious things and got nowhere. If this is Apple’s idea of “stepping over” whilst debugging, then perhaps I should just go back to Linux. I wonder if Ubuntu is usable again? Have they junked Unity and is GNOME 3 not stupid anymore?

What made me give up and walk away from the computer yesterday was discovering that concatenating strings in Objective-C isn’t as simple as doing this:

NSString *string = @”hello ” + @”world”;

The correct way is this:

NSString *string = [@”hello” stringByAppendingString:@”world”];

Which brings me to another thing, Objective-C’s “message expressions”. I sure do miss being able to type object.method()! Having to type an at-symbol before every Objective-C string is very annoying, but without it, I’m using C strings, which Objective-C doesn’t like. I’m sure Apple could do something here to deprecate this unfortunate requirement.

Given that XCode has really rubbed me the wrong way these past couple of days, I fell like being petty now :-) In .NET if you want to add a .ToMyString() method to the String class for use on any string, you add what’s called an extension method. Sounds logical, you’re adding a method to a system class, effectively “extending” the functionality of .NET itself. Now in Objective-C, an extension method is called a “category“. Beats me why they chose this name because it’s utterly illogical. Category of what? Anyway, “class extension” might be a logical name, but apparently such beasts were added in Objective-C 2.0 and are simply a way to allow a class to have private methods as far as I can tell right now (strange that a language would have no “private” method support until only recently). Objective-C is basically plain old C with Smalltalk-style object messaging syntax. Since then it has had various things done to it, such as Automatic Reference Counting and other afterthoughts. It’s now at a point where I seriously think Apple could do well to invest in a complete overhaul of the language and give it the ability to use another syntax scheme, much like .NET has c# and VB. I know I’m just dreaming, and that Apple would probably only make any such syntax bizarre in their own special way, so I suppose I’m just going to have to learn to live with Objective-C as it is, and embrace the joys that self-whipping can offer.

I suppose there’s always Xamarin.Mac, but I so wanted to really give Objective-C and XCode a try, but Apple are not making it easy for anybody with exposure to what I regard as “normal” development experiences, such as Java, C#, Perl, PHP, JavaScript, etc, and “normal” IDEs. I knew very well that Apple had their own special way of doing just about everything, and so far, since switching to Mac in December 2012, I’ve managed to cope well enough. It’s a very reliable platform, but it seems that if you want to do more than be just a passive consumer and internet surfer, you’re in for a bumpy ride. If I had only ever known the Apple way of doing everything, I’m sure I’d be right as rain, but having come from a different background, the transition for a developer is extremely unpleasant indeed.

They say that moving house and changing jobs are two of life’s most stressful events. I suppose switching from PC to Mac is another one, especially if you’re a developer! So far I’m determined not to be beaten, but I seriously needed to get all this off my chest. Only by venting will I be able to get past it and force myself into another whipping session tomorrow. Wish me luck!