Softwire Blog

Speed Coding 2016 – Q3 Solution

27 July 2016, by

This post explains the solutions to Question 3 of our speed coding 2016 competition. If you haven’t yet read the question, head back and have a go now.

(more…)

Speed Coding 2016 – Q2 Solution

20 July 2016, by

This post explains the solutions to Question 2 of our speed coding 2016 competition. If you haven’t yet read the question, head back and have a go now.

(more…)

Speed Coding 2016 – Q1 Solution

13 July 2016, by

This post explains the solutions to Question 1 of our speed coding 2016 competition. If you haven’t yet read the question, head back and have a go now.

(more…)

Server Components: Web Components for Node.js

11 July 2016, by

Web components logo

We at Softwire are big on open source. Many of us are involved in a variety of open-source projects, and some of us are even running our own, from database setup tools to logging libraries to archiving tools to HTTP performance testing and Roslyn-based code generators.

In this post I want to take a look at a recent new addition to this list: Server Components, a small library I’ve been working on to let you render web components entirely on the server-side.

Web components, for those not familiar, are a series of new specs coming (slowly) to browsers everywhere. It’s actually a set of 4 new features (Custom Elements, HTML Templates, Shadow DOM and HTML Imports), which together provide a fantastic, fast, built-into-the-browser way of defining brand new elements. You define your elements with their own internal rendering logic, presentation and behaviour, and then compose them together to build your page. Building your web page becomes a process of defining or just downloading small composable blocks, and then declaratively clicking them together.

There’s more to this than I can cover in this post, but if you’re interested in an intro then Smashing Magazine’s guide is a pretty good place to start.

These are a fantastic set of technologies if you’re looking for a nice way to build web applications on the client-side. They give you a tool to transform page build and JavaScript from being a fundamentally mess unstructured process (one enormous DOM, with everything operating at the same level of abstraction), to a manageable modern process, letting you layer abstractions atop one another and build your applications from many small standalone parts.

With web components, you can build web pages from independent encapsulated chunks of behaviour and UI. Within these web components, you can then nest other components, or pass them other components as input. Building a UI becomes much easier when your toolbox looks like:

 

<loading-spinner></loading-spinner>

<login-form action="/login"></login-form>

<qr-code data="http://example.com"></qr-code>

<calendar-date-picker value="2016-01-14"></calendar-date-picker>

<google-map lat=1234 long=5678 zoom=12></google-map>

<confirmation-dialog>
  Are you sure you want to quit?
</confirmation-dialog>

<item-paginator>
  <an-item>Item one</an-item>
  <an-item>Item two</an-item>

  ...

  <an-item>Item one thousand</an-item>
</item-paginator>

 

It’s a powerful paradigm, and this is really a standalone native version of the core feature that front-end frameworks like Ember, Angular and React have given us in recent years: the ability to powerfully compose together web pages quickly and easily out of smaller parts, while providing enough structure and encapsulation to keep them maintainable.

At the moment though, it’s a paradigm largely confined to the client-side. Clicking together server-side user interfaces has never really become an effective or enjoyable reality. You’re left with larger MVC frameworks that dictate your entire application structure, or trivial templating libraries that rarely offer more than token encapsulation or reusability. If you want a great experience for web UI development, you have to move to the client side.

Server Components aims to solve this. It’s taking the core of the client-side development experience, and moving it onto the server. Many web sites don’t need client-side interactivity but end up developing for client-side applications (and paying the corresponding costs in complexity, SEO, performance and accessibility) to get a better developer experience. Server Components is trying to give you that same power and flexibility to quickly build user interfaces on the web, without the client-side pain.

Screenshot of Tim.FYI

This is still early days for server components; I’m aiming to expand them significantly further as feedback comes in from more real world usage, and they’re not far past being a proof of concept for now. As a public demo though, I’ve rebuilt my personal site (Tim.FYI) with them, building the UI with delightful components like:

 

  <social-media-icons
    twitter="pimterry"
    github="pimterry"
    linkedin="pimterry"
    medium="pimterry"
  ></social-media-icons>

and even more complex ones, with interactions and component nesting:

 

  <item-feed count=20>
    <twitter-source username="pimterry" />
    <github-source username="pimterry" type-filter="PullRequestEvent" />
    <rss-source icon="stack-overflow" url="http://stackoverflow.com/feeds/user/68051" />
  </item-feed>

 

All entirely server-rendered, declarative and readable, and with zero client-side penalties. JavaScript is added on top but purely for extra interactivity and polish, rather than any of the core application functionality. Take a look at the full HTML, tiny chunk server code and the component sources to get a feel for how this works under the hood.

Interested? Want to go deeper and try this out yourself? Take a look at Server Components on Github.

Alternatively if you’d like some more detailed explanation first, take a look at the full introduction on Medium, complete with worked examples. If you’d like to hear even more about this, I’ll be talking to the Web Platform Podcast in more detail on July 17th, and feel free to send questions in on Twitter or in the comments below.

Speed Coding 2016 – Q4

6 July 2016, by

Here’s the 4th and final question from our last speed coding competition. This is a long and tricky one, so make sure you’ve put some time aside if you’re planning to try and solve it.

(more…)

Tips for remote working on the other side of the world.

4 July 2016, by

Like lots of people I’ve always liked the idea of remote working in exotic locations, but I recently had the opportunity to give it a go. I travelled halfway around the world and continued working for Softwire from New Zealand.

I enjoyed the experience, especially the 100% flexibility of knowing my team were all in bed: as long as I’d done a day’s work by the time they woke up, I could drop what I was doing and hit the beach or go for a long bike ride whenever the whim took me. On the downside there was almost complete isolation, access to the rest of the team was very limited and the brief period of overlap when I could actually talk to people became very valuable, even though it was at highly inconvenient times of day.

If you’re interested in more detailed advice about working remotely as a developer, see my original post on my personal blog: http://swilson.co.uk/blog/2014/09/11/working-remotely-in-a-dev-team/