Looking Back at 2018

The end of the year is typically a time to look back – here’s my personal list of programs and technologies that played an important role for me in 2018.

Visual Studio Code: It keeps getting better and better

This editor-becoming-an-IDE needs no introduction. I have included it in this list because 2018 was the year where I started doing meaningful work beyond editing HTML/[S]CSS files in Visual Studio Code.

For my purposes, it does not replace “classic” Visual Studio, but complements it. It’s not uncommon for me to debug ASP.NET Core and TypeScript code in Visual Studio Code as well as WPF code in Visual Studio 2018 at the same time (in a project where SignalR is used for Desktop Client <-> Server <-> Web Client communication).

I’m extremely impressed by the ecosystem of extensions (e.g. Live Sass Compiler, Live Server) as well as the ongoing development with its monthly releases.

Linea Sketch on iPad Pro: So good, it’s almost worth buying the hardware for

I love Linea Sketch, which is an iPad app for (as the name implies) sketching. When I tried out various graphics applications for my 2018 iPad Pro, I was looking for something that would allow me to quickly draw UI sketches and illustrations for presentations without much overhead. Linea Sketch caught my attention because of the combination of simplicity and power. Two highlight features of the app are “ZipLine” and “ZipShape”, which let you quickly draw straight lines, circles and polygons without breaking your flow of work with the pen.

Take a look at the Linea Sketch website to learn more about this fantastic app.

UWP: I wanted to like it, but what a disappointment…

I already wrote a bit about my frustration with the Universal Windows Platform (UWP) in the introduction to my previous blog post.

Obviously, each new platform comes with a learning curve. If you have a clear vision of what you want to develop and are learning how to do it along the way, you are bound to take longer than expected. What happened with UWP, though, was that I encountered problems that too often became roadblocks for hours or sometimes days. If you get silent crashes or low-level exceptions with an HRESULT that basically says, “something went wrong”, the only thing you can do is to comment out code you have just written up to a point where the program is working again. That reminded me very much of the early Silverlight days (version 2 and 3), Back then, error messages only became helpful in later versions (I remember version 4 and 5 as being good enough).

Web searches showed me that I wasn’t alone. Every so often, a question on a forum would made me go “yeah, I’d like to know an answer to that, too”. Unfortunately, often only reply would clearly indicate that the original post was only scanned for keywords, not actually read, let alone understood. Obviously, this is not a specific UWP problem. It’s just that other technologies seem to have reached a critical mass of users, so that e.g. on StackOverflow, additional comments and answers appear quicker and in larger numbers.

The final straw for me were silent crashes of the Windows App Cert Kit, which had worked on my machine earlier. Searching for a solution, I came across Microsoft forum threads reporting WACK problems that went on for months, with no real solution in sight.

I don’t know whether the WACK problem has been solved now, or whether UWP in general has become friendlier in terms of developer experience. But frankly, I have stopped caring. After all, we’re talking about programming as a hobby. Maybe I’ll revisit UWP in a few years – but for now, I have moved on.

And by the way: I actually do like UWP APIs. They make e.g. creating a thumbnail of a media file or determining the length of a video file super-easy. But I can use these APIs from a WPF program as well, so that’s exactly what I’m doing now.

ASP.NET Core (Web API, SignalR): A positive surprise

While working with UWP was hard work for every step along the path, ASP.NET Core was clearly the opposite experience for me. Whenever I ran into a problem, I found a sample or some forum or StackOverflow post that helped me find a solution. And unlike with UWP, where I came from a WPF and Silverlight background, I didn’t have much prior knowledge.

To put things in perspective:

  • I started with version 2.1, i.e. I surely skipped a lot of the problems of the 1.x days.
  • I found a great starting point with the SignalR with TypeScript and WebPack sample.
  • I use ASP.NET for non-UI, server-related functionality that is limited in scope.

So, your mileage may vary. For me, the positive initial experience was a great motivation to learn more about the platform and to overcome the small problems that are simply a natural part of software development.

3 Comments

  • Thanks for this writeup. I have come to similar conclusions with UWP - even my experiments were harder than they should have been. I've stuck with WPF as well. I'd be interested in a blog post (if you have the time and interest) about how you're combining WPF with SignalR. I am a WPF desktop dev by day and am still excited and interested in WPF improveements -- will be carefully looking into .NET Core WPF support once it's far enough along to warrant the time spent.

    John

  • Hi John,
    Thank you for your comment and your suggestion. I have started a blog post (3/4 finished) about why and how I have used Web API and SignalR for splitting a WPF application into two SignalR clients and one server. The post is less about the technical aspects (I found the Microsoft docs pretty helpful for that), but more from a conceptual point of view (what, when, for what). The text needs some more work and I have other things coming up in the next days, but this will definitely become my January post!

    Roland

  • Hi John,
    the article is online. I hope it contains interesting bits for you.
    https://weblogs.asp.net/rweigelt/wpf-with-web-api-and-signalr-why-and-how-i-use-it

Add a Comment

As it will appear on the website

Not displayed

Your website