This the first post of a series on web API polyfill libraries. In this post, we are going to discuss why polyfill is a good idea and what are some of the cool modern web APIs coming to browsers. In the second one, we will discuss some of the drawbacks current polyfill libraries have and also challenges of writing good polyfill libraries. And finally, we take polyfill libraries to the next level by discussing a whole new way of consuming them.

Introduction to Polyfill

The term polyfill in front end world means code that provides APIs the browser is supposed to offer natively, if they are currently missing. Here is some sample polyfill code, which makes Date.now defined in ECMAScript v5 available to all browsers:

if (!Date.now) {
    Date.now = function now() {
        `return new Date().getTime()`
    }
}

A polyfill library is in direct contrast to a library like jQuery, where it invents its own APIs to provide the missing implementations:

timeLib.epoch = Date.now || function now() {
    `return new Date().getTime()`
}

Given the two styles of methods to bridge the gaps between browsers with varying degree of standard conformance, which one is better?

Context

Many times in my career, I had to face cases where I had to keep a history of one or many tables. Most of the time, the need of history comes after the main feature itself is developed and ends up in this kind of architecture:

| Post         |   | PostHistory   |
|==============|   |===============|
| author_id    |   | post_id       |
| title        |   | title         |
| content      |   | content       |
| published    |   |---------------|
| published_at |
|--------------|

It comes as the most natural and painless way to add the history feature to an existing entity. You can also find gems doing this job for you, in which case, they will serialize your Post in a generic history table.

Both of those approaches sound sexy because they’re simple to implement and they don’t introduce a “risk” for the Post model. Problem is, they’re very hard to maintain.

Arthur Wang is our “new” iOS developer. Alright, he is not new. He has been on this team for more than 1 year. The iOS app Strikingly is developed by him.

The family name Wang in Chinese means KING, so we literally call him “King Arthur” in Chinese.

When I first learned about shadows in CSS3, I was like “Oh, cool.” I kind of shrugged it off, since it didn’t feel particularly world-changing. But as I built more and more websites, I’ve found that shadows are awesomely flexible, especially for a handful of particularly beautiful, subtle effects.

A Naive Example

<style>
  div { 
    background: orange; 
    box-shadow: 5px 10px 7px rgba(0,50,100,0.65); 
  }
</style>
<div> Hello World </div>

That’s a great example of how not to use shadows — it’s loud, obnoxious, and just ugly. It reminds us of the late 90s when we just discovered shadows in Photoshop or MS Word and we just threw them on everything.

New Frontend Engineer

We are delighted to welcome Chris Han to the front-end team!

Chris is a senior student from Sun Yat-sen University in Guangzhou. He loves Chinese eight-ball and dreams of making clearance with one chance. He believes that God is equal to everyone, because every second of everyone’s life is same in length. He used to like hamburgers.

New Frontend Engineer

We’re very excited to welcome Andrew to the frontend development team here at Strikingly! He comes to us from the world of big red trucks, where he spent multiple years learning how to prevent many things from lighting on fire or burning down. Between that and keeping the neighborhood alive and healthy, it seems natural that he would try to apply the same care and concern for the websites people use every day.

This is the first blog post of a series I’d like to write about caching and how caching improves the performance of Strikingly.

Introduction to HTTP Cache

The basic idea of caching is based on the principle of locality, a phenomenon where the same data is accessed frequently within a relatively short time, which means we can store this data in media with higher access speed to significantly boost system performance.

（本文基于达峰的分享扩充而成，并刊登在 CSDN 程序员杂志8月A上）

探索 React 生态圈

2004年，对于前端社区来说，是里程碑式的一年。Gmail 横空出世，它带来的基于前端渲染的原生应用级别的体验，相对于之前的服务端渲染网页可谓提升了一个时代，触动了用户的G点。自此，前端渲染的网站成为无数开发者追逐的方向。

为了更好地开发前端渲染的「原生级别的」网站，包括 Backbone 和 Angular 在内的一系列前端框架应运而生，并迅速获得了大规模的采用。但是很快地，新的性能和 SEO 问题也接踵而来。几经尝试后，Twitter 甚至从前端渲染重回服务器渲染，而 Strikingly 也面对过同样棘手的问题。

2014年，React 进入我们的视线。让人耳目一新的是，对于其他开源框架遇到的种种问题，React 都自信地给出了解答。几乎没有犹豫，我们开始使用 React 来重构 Strikingly。若干年后，当我们回望，也许会发现， 2014年也是前端社区里程碑式的一年。

React 带来的革命性创新是前端世界过去几年最激动人心的变化。自从接触 React 以来，我深信 React 会改变客户端开发者（包括前端、iOS 和 Android）的开发体验。这次在巴黎举办的 ReactEurope Conf 大会是继第一次在 Facebook 总部举办后最大的 React 活动。超过10位来自React、GraphQL、Relay 团队的核心技术成员也出席大会进行分享。这次代表 Strikingly（似乎也是国内唯一家公司）去参加，想写下一些参会感想。

Keynote [1] 讲师是来自 Facebook 的 Christopher Chedeau (vjeux)。他分享了 React 生态系统四大方面 （Data, Targets, Language, Packager）的变化。这次大会所有的内容我觉得也都是这四方面的延伸。我印象最深的是 Data 和 Targets，也是这篇文章主要想分享的内容。