Captain Codeman


Tag: web-components

Web Development Without a Framework

How difficult is it to assemble the pieces you need

As President Kennedy implored:

“My fellow developers, ask not what your Framework can do for you. Ask what you can do for your framework!”.

Yeah, I know, not quite the exact quote. But sometimes it feels that you have to do more to help your framework work than your framework does to help you.

Two years ago I was working with Angular 2 and if you managed to get your compressed javascript payload under 200Kb you thought you were doing pretty well. I remembered about it when I realized I can now have an app with far more functionality and be easily within 15Kb.

Maybe it’s time to ask yourself, what is your Framework really doing for you … and do you still need it?

angular redux web-components polymer

Do you still need that framework?


Thoughts on Polymer 3.0 after Polymer Summit 2017

How I think I'll be writing web apps a year from now

First of all, let me make clear that I have no inside knowledge and am not privy to any secrets - my views are based purely on using the platform, hanging out in Slack and watching the presentations.

It’s also maybe useful to describe where I “am” as a web developer. I used to use Angular 1 and then 2, never really cared much for React but was aware of it (and like Redux) but was totally sold on WebComponents and the benefits of any framework being built on the platform. When Angular 2 turned out to be a huge letdown and Polymer had turned 1.x it was time to change and I’ve been happy with the choice. I find it quicker to develop apps and I’m spending more time on app-development and much less on endless framework upgrades plus the end results start and run faster.

polymer web-components redux

disappointment and anticipation


Building a Micro Startup Part 2: Design & Prototyping

Picking the right technologies

One of the mistakes I saw a lot of when Agile was taking off as “the hot-new thing” was people declaring that they didn’t need to do design anymore. Of course there was no big-upfront design - the kind from the waterfall days where people first analyzed and designed a system in full before punting it to the next team to build (which rarely worked out well) but some planning and design is important, even if you’re just creating a small hobby project.

Part of the process should often involve prototyping to help decide or prove which technologies you’re going to use as these will also factor in to the design of the app. It also gives you an opportunity to kick-the-tires of some technologies if they are things you haven’t used much before prior to building too many things around them. Making late-stage switches can be costly.

This isn’t going to be an exhaustive comparison of every possible client-side framework, storage technology or hosting option. Of course I have some technology choices in my head before I even begin based on my current skillset and experience (isn’t it an amazing coincidence that the “best” technology to build any app with is always the one the developer likes to use?!) But I’ll try to go through the reasoning behind some of the choices I came up with.

go golang firebase appengine polymer web-components

Read more about the design process and prototyping ...


WebComponents vs Framework Specific Components

Why generic components are a much better investment

We’ve all seen and used them, we may even have written some ourselves. They seem such a great idea at the time and using them seems to make life easier. I’m talking about Framework Specific Components.

I want to talk about why WebComponents are much better and they should be the first think we look to use and create whenever possible.

web-components polymer

Read more ...


How WebComponents Make Site Upgrading Easier

Because switching Frameworks is hard

While we’re used to systems nowadays being distributed and running across multiple services on multiple platforms when it comes to front-end web clients many people still have a rather “monolothic” outlook on things.

Many times this is down to technology imposing restrictions on us - it’s difficult enough to make some frameworks and all their component pieces work together to deliver an app without also throwing in the challenge of making multiple different frameworks coexist (part of the problem with the rise of “frameworks” instead of libraries).

It can be particularly problematic when an aging app needs to be upgraded. You may have an Angular.JS app and be faced with the choice of whether to re-write it as an Angular v2 / v4 app or switch to using the Redux / React stack instead.

Both represent a lot of work and the difficulty making frameworks coexist can be a real challenge with any attempts at doing things incrementally. This is where WebComponents can really help.

web-components polymer angular web-frameworks

Read more ...


Polymer Web-Components for Markdown Image Upload

Creating a great image upload experience with Markdown

One of the great things about Polymer and Web-Components is they are part of the platform. What I mean by that is that once you define an element, you can add some HTML containing a reference to it however and wherever you like and the browser will render it.

Not all JavaScript frameworks can do that. Amazingly, some front-end frameworks don’t seem to be able to handle HTML unless it’s HTML that they are generating. Set some innerHTML and even though it may contain elements defined in the app, they won’t appear.

To show how useful it is, imagine we want to implement a markdown editor with Ghost-like image uploading …

polymer web-components blogserve

Read more ...


Polymer 2 - the 10Kb Web Framework

The age of the dinosaur monster web frameworks is ending

I saw this data from a Polymer product manager buried in a GitHub issue comment and thought it was worth highlighting to show just how amazing Polymer 2.0 is when it comes to framework-size. Many JS frameworks have made grand promises about the small size of their apps but it’s usually only after an inordinate amount of work and effort that you even get close to the promised values, if at all (my Angular 2 app was never anything buy huge).

Polymer is very different to many of the JS-first frameworks in that it builds on the web platform instead of trying to reproduce and replace so much it - because browsers are actually very good at parsing HTML and rendering it quickly if only you let them get on with it (yeah, who knew!).

So instead of trying to offer as many features as possible (does anyone really need “dependency injection” for a JavaScript web app?) it instead tries to add as little as possible, deferring to the functionality already built into the platform whenever possible. The result is a light sprinkling of features on top of what the browser does and does fast, adding data-binding, dealing with cross-browser compatibility when needed etc… and more recently, handling compatibility between v1 and v2 of Polymer and v0 and v1 of web-components.

Here are the individual + combined sized of the different Polymer versions together with the Polyfills required in each browser …

polymer web-components web-frameworks javascript

Read more ...


Polymer 2.0 - Simple and Elegant

Web client frameworks don't have to be complicated

If you’ve been involved in front-end web development for the past few years you will no doubt have come across the concept of “JavaScript Fatigue”.

It’s the result of constant and seemingly endless changes, reinventions and releases of tooling and frameworks that you feel you need to keep up with.

Often it seems like something is invented so solve one problem but brings with it more issues. And in the world of JavaScript there’s nothing that can’t be fixed by new tooling … always, oh so many tools.

But things are going to change …

polymer web-components

Read more ...