346 lines
29 KiB
XML
346 lines
29 KiB
XML
<?xml version="1.0" encoding="utf-8"?>
|
||
<feed xmlns="http://www.w3.org/2005/Atom">
|
||
|
||
<title><![CDATA[Category: Technology | Home Assistant]]></title>
|
||
<link href="https://home-assistant.io/blog/categories/technology/atom.xml" rel="self"/>
|
||
<link href="https://home-assistant.io/"/>
|
||
<updated>2017-07-20T15:38:20+00:00</updated>
|
||
<id>https://home-assistant.io/</id>
|
||
<author>
|
||
<name><![CDATA[Home Assistant]]></name>
|
||
|
||
</author>
|
||
<generator uri="http://octopress.org/">Octopress</generator>
|
||
|
||
|
||
<entry>
|
||
<title type="html"><![CDATA[ZWave Entity IDs]]></title>
|
||
<link href="https://home-assistant.io/blog/2017/06/15/zwave-entity-ids/"/>
|
||
<updated>2017-06-15T12:00:00+00:00</updated>
|
||
<id>https://home-assistant.io/blog/2017/06/15/zwave-entity-ids</id>
|
||
<content type="html"><![CDATA[ZWave entity_ids have long been a source of frustration in Home Assistant. The first problem we faced was that depending on the order of node discovery, entity_ids could be discovered with different names on each run. To solve this we added the node id as a suffix to the entity_id. This ensured that entity_ids were generated deterministically on each run, but additional suffixes had to be added to handle edge cases where there would otherwise be a conflict. The resulting entity_ids worked, but have been difficult to work with and makes ZWave a strange exception among other Home Assistant components.
|
||
|
||
Thanks to the awesome work of [@turbokongen], a growing number of ZWave configuration options are now available from the new ZWave panel in the Home Assistant frontend. Among these new features is support for renaming of ZWave nodes and their underlying values. (These renames are persisted in zwcfg_*.xml) This is important, because these items are combined to form the Home Assistant entity name, which is used to generate the entity_id. Now that these options are available, ZWave users can rename nodes and values, influencing the entity_ids that are generated by Home Assistant.
|
||
|
||
Now that users are able to control these names, we will be making changes to how the entity_ids are generated for ZWave entities. The ZWave entity_ids are going to switch back to using the standard entity_id generation from Home Assistant core, based on the entity names. Moving forward, if there is a conflict when generating entity_ids, a suffix will be added, and it will be the responsibility of the user to rename their nodes and values to avoid the conflict. This is the same as any other platform in Home Assistant where two devices are discovered with the same name.
|
||
|
||
With the release of 0.47, this feature will be opt-in. Setting `new_entity_ids: true` under `zwave:` in your configuration.yaml will enable the new generation. After 0.48 this feature will become opt-out. From 0.48 onward, unless you’ve declared `new_entity_ids: false` you will switch to the new entity_id generation. At an undecided point in the future, the old entity_id generation will be removed completely.
|
||
|
||
I’m sure all ZWave users understand that the current entity_ids aren’t easy to use. They’re annoying to type in configuration.yaml, and break if a node needs to be re-included to the network. We know that breaking changes are painful, and so we’re doing what we can to roll this change out as smoothly as possible. The end result should be a dramatic simplification of most ZWave configurations. We hope that this change will ultimately make ZWave much easier to work with, and bring ZWave configuration just a little closer to the rest of the Home Assistant platforms.
|
||
|
||
[@turbokongen]: https://github.com/turbokongen
|
||
]]></content>
|
||
</entry>
|
||
|
||
<entry>
|
||
<title type="html"><![CDATA[HASSbian 1.21 - It's about time isn't it]]></title>
|
||
<link href="https://home-assistant.io/blog/2017/04/30/hassbian-1.21-its-about-time/"/>
|
||
<updated>2017-04-30T15:00:00+00:00</updated>
|
||
<id>https://home-assistant.io/blog/2017/04/30/hassbian-1.21-its-about-time</id>
|
||
<content type="html"><![CDATA[### Hassbian 1.21 - It's about time isn't it
|
||
Since I, the developer of HASSbian, have been moving, started a new job and so on I've had few moments over for HASSbian development. The 1.2 release has been in pre-release for a few months now and just not communicated out that well. Hopefully this release changes that and I'll do my best to release more often. There's no simple way to update from 1.1 to 1.21 but 95% of the changes can be done by installing the [hassbian-config][hassbian-config-release] package. For more information have a look at the [hassbian-config][hassbian-repo] page.
|
||
|
||
### Hassbian 1.22 - Sins of last night
|
||
Development is sometimes fast and joyful but mistakes are made at times.
|
||
|
||
With the release of 1.21 a small problem with the OpenZWave build script wasn't corrected even tough it was a known bug. Problem is simple as it's only a problem with the symlink created for to the configuration folder for OpenZWave. This has been fixed and we bring some new things since they where ready anyway. The list below has been augmented with the updated information.
|
||
|
||
### <a class='title-link' name='hassbian-config' href='#hassbian-config'></a> Hassbian-config
|
||
|
||
To allow you to customize your installation further, we have included a tool called `hassbian-config`. This tool comes with a set of packages that can easily be installed for easier customization of your Home Assistant installation. This replaces the `hassbian-scripts` functionality from 1.1.
|
||
|
||
- Install Hue. Configures the Python executable to allow usage of low numbered ports for use with Emulated Hue component thats used with Amazon Echo, Google Home and Mycroft.ai.
|
||
- Install Mosquitto MQTT server. Installs the latest Mosquitto package and client tools from the Mosquitto projects official repository. Now includes websocket support.
|
||
- Install Libcec. Adds local [HDMI CEC support][cec].
|
||
- Install Open Z-Wave-pip. Installs Python Open Z-Wave from a pip package. This is the quickest and recommended way of installing Z-Wave support but does not OZWCP pre-installed.
|
||
- Install Open Z-Wave. Installs Python Open Z-Wave and OZWCP from git.
|
||
- Install Samba. Allows anyone on your network to edit your configuration from any computer. This share is unsecured and it's usage is not recommended if you share your network with others.
|
||
- Install Tellstick. Installs the Tellstick package for controlling and using a connected Tellstick.
|
||
- Install Tradfri. Installs dependencies for using IKEA Trådfri.
|
||
|
||
### <a class='title-link' name='spring-cleaning' href='#spring-cleaning'></a> Spring cleaning
|
||
|
||
With this image there also quite a bit of cleaning of the base system and the script that generates our Raspberry Pi image.
|
||
|
||
- Replaced the `hassbian-scripts` folder with `hassbian-config`.
|
||
- Update `pi-gen`. Our build script has been upgraded to follow the Raspbian image closer once again. Now you could build this image with Docker if your so inclined.
|
||
- Added libtool and autoconf package. Dependencies for some of the pip packages.
|
||
- Pi ZeroW should now work with the image.
|
||
|
||
To follow discussions about the development of the HASSbian image or to contribute join our [Discord chat server][discord-devs].
|
||
|
||
To get started with the new image, check out the installation instructions in the [getting started section][gs-image].
|
||
|
||
[cec]: /components/hdmi_cec/
|
||
[hassbian-repo]: https://github.com/home-assistant/hassbian-scripts/
|
||
[hassbian-config-release]: https://github.com/home-assistant/hassbian-scripts/releases/latest
|
||
[gs-image]: /getting-started/installation-raspberry-pi-image/
|
||
[discord-devs]: https://discord.gg/8X8DTH4
|
||
]]></content>
|
||
</entry>
|
||
|
||
<entry>
|
||
<title type="html"><![CDATA[HASSbian 1.1 - The Toy-box]]></title>
|
||
<link href="https://home-assistant.io/blog/2017/02/04/hassbian-toybox/"/>
|
||
<updated>2017-02-04T09:00:00+00:00</updated>
|
||
<id>https://home-assistant.io/blog/2017/02/04/hassbian-toybox</id>
|
||
<content type="html"><![CDATA[Tonight I'm happy to announce a new release of the our Raspberry Pi image, **HASSbian 1.1 - The Toy-box.**
|
||
Why Toy-box you wonder? Because it encompass the changes pretty well.
|
||
|
||
Changes from previous image are big and small but lets start with the interesting things.
|
||
|
||
### <a class='title-link' name='hassbian-scripts' href='#hassbian-scripts'></a> Hassbian-scripts
|
||
A set of script written to add extra functionality to your Raspberry Pi installation.
|
||
This scripts are run as the `pi` user and installs a set of tools or packages.
|
||
Currently includes:
|
||
- Install Libcec. Adds local [HDMI CEC support][cec].
|
||
- Install Mossquitto. Installs the latest Mosquitto package and client tools from the Mosquitto projects official repository. Now includes websocket support.
|
||
- Install OpenZWave. Installs OpenZWave and prepares for using a USB or GPIO ZWave controller.
|
||
- Install Samba. Installs the Samba packages and shares your configuration over smb to be available to edit on any computer without the need for separate file transfer software. This share is unsecured and it's usage is not recommended if your installation is publicly available.
|
||
|
||
All of these scripts are available in the directory `/home/pi/hassbian-scripts/`. This directory is actually a cloned git repository that's cloned on first boot and can be updated to the latest release with ease after.
|
||
To update the hassbian-scripts directory execute the following command as the `pi` user.
|
||
```bash
|
||
$ cd hassbian-scripts
|
||
$ git pull
|
||
```
|
||
To use any of the hassbian-scripts, execute the following command as the `pi` user. Here we use the libcec script as an example.
|
||
```bash
|
||
$ sudo ./hassbian-scripts/install_libcec.sh
|
||
```
|
||
|
||
For more information about these scripts have a look a the [hassbian-scripts repository][hassbian-repo].
|
||
|
||
### <a class='title-link' name='spring-cleaning' href='#spring-cleaning'></a> Spring cleaning
|
||
With this image there also quite a bit of cleaning of the base system and the script that generates our Raspberry Pi image.
|
||
- Update pi-gen. Our build script has been upgraded to follow the Raspbian image closer. This image is basically a Raspbian lite image with Home Assistant, dependencies and a small set of changes to the base system.
|
||
- Removed Mosquitto. Not as bad as it sounds since it's installation has been move to one of our new hassbian-scripts.
|
||
- Added rng-tools. Let's your HASSbian installation use the hardware support in the Raspberry Pi for entropy generation.
|
||
- Added avahi-daemon package. Your Raspberry Pi should now be available at [hassbian.local][hassbian-avahi].
|
||
- Added htop. User friendly interactive process monitor.
|
||
- Added tmux. A great terminal multiplexer that makes working with the command line over ssh easier.
|
||
- Added the `homeassistant` user to the `dialout` group. Simplifies use of hardware such as ZWave USB controllers that requires this permission.
|
||
|
||
### <a class='title-link' name='on-the-horizon' href='#on-the-horizon'></a> On the horizon
|
||
There's of course more on the horizon and there's even more plans and wishes for how this image will function in the future.
|
||
On the close horizon from [@Landrash][landrash-github] there a few more script in the works and for tellstick, emulated_hue and for controlling Home Assistant.
|
||
|
||
To follow discussions about the development of the HASSbian image or to contribute join our [Discord chat server][discord].
|
||
|
||
To get started with the new image, check out the installation instructions in the [getting started section][gs-image].
|
||
|
||
[cec]: /components/hdmi_cec/
|
||
[hassbian-repo]: https://github.com/home-assistant/hassbian-scripts
|
||
[hassbian-avahi]: hassbian.local
|
||
[landrash-github]: https://github.com/Landrash
|
||
[gs-image]: /getting-started/installation-raspberry-pi-image/
|
||
[discord]: https://discord.gg/8X8DTH4
|
||
]]></content>
|
||
</entry>
|
||
|
||
<entry>
|
||
<title type="html"><![CDATA[We have a Raspberry Pi image now]]></title>
|
||
<link href="https://home-assistant.io/blog/2016/10/01/we-have-raspberry-image-now/"/>
|
||
<updated>2016-10-01T05:00:00+00:00</updated>
|
||
<id>https://home-assistant.io/blog/2016/10/01/we-have-raspberry-image-now</id>
|
||
<content type="html"><![CDATA[Today we're happy to announce our brand new Raspberry Pi image! It is based on Raspbian Lite combined with HASS so we decided to call it Hassbian.
|
||
|
||
This image comes pre-installed with everything you need to get started with Home Assistant right away.
|
||
|
||
To get started, check out the installation instructions in [the getting started section][gs-image] or watch the latest video by [BRUHAutomation]:
|
||
|
||
<div class='videoWrapper'>
|
||
<iframe width="560" height="315" src="https://www.youtube.com/embed/iIz6XqDwHEk" frameborder="0" allowfullscreen></iframe>
|
||
</div>
|
||
|
||
### <a class='title-link' name='under-the-hood' href='#under-the-hood'></a> Under the hood
|
||
|
||
It's based on Raspbian Lite and generated with a fork of the same [script](https://github.com/home-assistant/pi-gen) that builds the [official Raspbian images](https://raspberrypi.org/downloads/raspbian/). For installation of HASS it follows the same install instructions as the [Manual installation](/getting-started/installation-raspberry-pi/). Please note that this project has no association with the Raspberry Pi foundation or their projects.
|
||
|
||
On first boot the latest release of Home Assistant will be installed and can be reached after 3~5 minutes. Pre-installed on this image is the MQTT broker [Mosquitto](https://mosquitto.org/), Bluetooth support and settings for the `homeassistant` account to use the GPIO pins of the Raspberry Pi. Mosquitto is not activated by default.
|
||
|
||
As it is today there is no pre-compiled Z-Wave support but it can be installed by following the [Getting started instructions for Z-Wave](/getting-started/z-wave/).
|
||
|
||
Happy Automating!
|
||
|
||
[gs-image]: /getting-started/installation-raspberry-pi-image/
|
||
[BRUHAutomation]: https://www.youtube.com/channel/UCLecVrux63S6aYiErxdiy4w
|
||
]]></content>
|
||
</entry>
|
||
|
||
<entry>
|
||
<title type="html"><![CDATA[Optimizing the Home Assistant mobile web app]]></title>
|
||
<link href="https://home-assistant.io/blog/2016/08/07/optimizing-the-home-assistant-mobile-web-app/"/>
|
||
<updated>2016-08-07T19:36:00+00:00</updated>
|
||
<id>https://home-assistant.io/blog/2016/08/07/optimizing-the-home-assistant-mobile-web-app</id>
|
||
<content type="html"><![CDATA[_This blog post will go into detail about the recent performance optimizations that went into the Home Assistant front end. For people not familiar with the app, check out [the demo][demo] and [the source][hap]._
|
||
|
||
TL; DR: Don’t hack the framework, separate responsibilities, ship less, use service workers, use (future) web standards.
|
||
|
||
This year at Google I/O I saw Monica from the Polymer team talk about web components and performance. In her talk [she mentions a mantra][mantra] that they use in the Polymer team to make things fast: **Do less and be lazy**.
|
||
|
||
Do less and be lazy. It sounds so obvious and it took a while before it started to dawn on me. I think most of the code I write is pretty fast, but I don't often stop to take a harder look at how and when it runs in practice. When do we need the result, can it be postponed?
|
||
|
||
And thus started my journey to take a critical look at how the Home Assistant app was working and how to make things faster. Below is the list of the different things that I did to make it fast.
|
||
|
||
I hope this list can be useful to other people, as a guide for optimizing their own apps or for avoiding pitfalls when building a new one.
|
||
|
||
The first thing to do is to measure. The Home Assistant front end is a mobile web app, so we shouldn’t measure this on a machine with 8 cores and gigabytes of ram but instead measure on devices you expect a mobile web app to run: phones. Below are two timelines recorded with Home Assistant 0.18.2 (pre-optimizations) and Google Chrome 53. **On my Mac the app starts in 1400 miliseconds and on my Nexus 5x in ~6500 miliseconds (~4.5 times slower!).**
|
||
|
||
<p class='img'>
|
||
<img
|
||
src='https://home-assistant.io/images/blog/2016-08-optimizing-web-app/performance-timeline-0.18.2.png'
|
||
alt='Timeline of loading the front end in Home Assistant 0.18.2' />
|
||
</p>
|
||
|
||
Although the app takes 6500 milliseconds to load on my phone, it would perform well afterwards. Still, that initial load is unacceptable. You expect to open an app on your phone and be able to use it, quickly. After I applied all the changes described below, I managed to reduce startup time to 900 miliseconds (-35%) on my Mac and 2400 miliseconds (-63%) on my Nexus 5x. [Check out the demo here.][demo]
|
||
|
||
<p class='img'>
|
||
<img
|
||
src='https://home-assistant.io/images/blog/2016-08-optimizing-web-app/performance-diagram.png'
|
||
alt='diagram showing old and new loading times next to one another' />
|
||
<img
|
||
src='https://home-assistant.io/images/blog/2016-08-optimizing-web-app/performance-timeline-0.26.png'
|
||
alt='Timeline of loading the front end in Home Assistant 0.26' />
|
||
</p>
|
||
|
||
<!--more-->
|
||
|
||
## <a class='title-link' name='technology' href='#technology'></a> Technology
|
||
|
||
The Home Assistant front end consists of two parts. There is [Home Assistant JS][hajs], which controls all data and interaction between JavaScript and the server. It is a Flux architecture using [NuclearJS] and [ImmutableJS]. The UI is implemented by [Home Assistant Polymer][hap] using [Polymer] and web components.
|
||
|
||
# <a class='title-link' name='dont-hack-the-framework' href='#dont-hack-the-framework'></a> Don’t hack the framework
|
||
|
||
I thought to be smart. I split out the JavaScript part of all web components and bundled them separately using Webpack so that I could use ES2015 via BabelJS ([architecture][es2015-arch]). This is not how Polymer components are written and it meant that I was unable to use any of the tooling that is available in the community or easily split up the bundle (more on this later).
|
||
|
||
So I went ahead and backported all my web components back from shiny beautiful ES6 to ES5. And you know what? It’s not that bad. Yes, not being able to use the concise object notation and arrow functions make your code more verbose. But in the end it is the same code that is running in browsers.
|
||
|
||
Another benefit of having each web component contain their own script tag is that the browser will process them one by one, allowing the browser to render our loading spinner animation in between.
|
||
|
||
As you can see in the timelines, we were able to get rid of most of the blocking component loading.
|
||
|
||
<p class='img'>
|
||
<img
|
||
src='https://home-assistant.io/images/blog/2016-08-optimizing-web-app/timeline-no-more-es2015.png'
|
||
alt='Timeline of loading the front end before and after the optimization' />
|
||
</p>
|
||
|
||
# <a class='title-link' name='separate-responsibilities' href='#separate-responsibilities'></a> Separate responsibilities
|
||
|
||
Whenever you learn a new technology, you feel like you’ve learned a new superpower. Wow, I can do all this with only 2 lines?! I had the same with bundling.
|
||
|
||
I was initially very focused on shipping just a single file with everything that my app needed. The entry point would be my main component which would require all of its Flux and UI dependencies. Then, just before it all would be rendered, it would check if there is authentication and start the data fetching.
|
||
|
||
This is a very bad pattern. This means that you will not start any data fetching until your UI is ready to render. Instead, you want your data to be fetched as soon as possible, and while the request is out to the server you want the page to load all your UI components.
|
||
|
||
To accomplish this I extracted the application core out of the main bundle. In the current optimized version it’s 31.1kb gzip’d. It is loaded before any other scripts so that it can start fetching data as soon as possible.
|
||
|
||
<p class='img'>
|
||
<img
|
||
src='https://home-assistant.io/images/blog/2016-08-optimizing-web-app/timeline-corejs.png'
|
||
alt='Timeline of loading the front end before and after the optimization' />
|
||
</p>
|
||
|
||
When the data does come back before the UI is done loading, we can process it before we start rendering the UI because of all the web components being processed individually. This means that we don't have to show a loading screen the first time our components render – we can just render the components with the data they require.
|
||
|
||
# <a class='title-link' name='ship-less' href='#ship-less'></a> Ship less
|
||
|
||
The theory behind this one is simple: if we manage to ship less code, the browser has to process less code and it will start faster.
|
||
|
||
## <a class='title-link' name='only-include-the-components-for-the-page-that-you-will-show' href='#only-include-the-components-for-the-page-that-you-will-show'></a> Only include the components for the page that you will show
|
||
|
||
The Home Assistant mobile web application has 10 different panels (pages). Besides that, it also has a dialog for each type of device to show more info. That’s a lot of components and screens of which only a very small set is needed at the start. That means that we are shipping a lot of unnecessary data that the browser has to process before our initial render!
|
||
|
||
I broke up each panel of the app into a separate bundle that will be loaded on demand. This saved 250 kilobytes (pre-gzip) on just the embedded map alone! This change, however, required some significant changes to our build process.
|
||
|
||
Breaking up an app in JavaScript is complex because each module explicitly imports their dependencies. This has to continue to work in your browser after breaking it up in multiple files. Web components do not have this problem as it’s part of the platform and thus your browser is the registry! An unregistered web component will be rendered as an empty span element until the element gets registered. Loading order is not important.
|
||
|
||
```javascript
|
||
// Example of the flexibility of web components.
|
||
var spinner = document.createElement('paper-spinner');
|
||
spinner.active = true;
|
||
document.body.appendChild(spinner);
|
||
```
|
||
|
||
Because the browser tracks your web components, creating standalone bundles for parts of the app is easy:
|
||
|
||
- Find all dependencies included in the main bundle (using [hydrolysis])
|
||
- Create individual bundles of each panel (page) but filter out the dependencies included in main bundle.
|
||
|
||
The [build script][build-html] that bundles and minifies the main bundle and panel bundles is <100 lines.
|
||
|
||
## <a class='title-link' name='change-the-javascript-bundler-to-rollup' href='#change-the-javascript-bundler-to-rollup'></a> Change the JavaScript bundler to Rollup
|
||
|
||
Core.js is still pure JavaScript and requires bundling. In my journey to get a smaller bundle, I went from [Webpack] to Webpack 2 to [Rollup]. At each step the bundle got smaller. Rollup is the big winner here because it doesn’t wrap all your modules in function calls but instead concatenates all files with minimal changes to make it work. This not only reduces the file size but also the loading speed. This is because the JavaScript engine will no longer have to invoke a function to resolve each import, it’s doing less work. This might not mean much for a computer but on a phone, everything counts.
|
||
|
||
## <a class='title-link' name='scrutinize-dependencies' href='#scrutinize-dependencies'></a> Scrutinize dependencies
|
||
|
||
If the goal is to ship less, it’s time to take a good look at dependencies. It’s so often that we decide to fall back to yet another NPM package that makes our life a little easier but comes at the cost of size – size usually taken up by functionality that you might never need.
|
||
|
||
### <a class='title-link' name='remove-lodash' href='#remove-lodash'></a> Remove Lodash
|
||
I realized that I only used a few methods of lodash. Lodash (and previously underscore) used to be one of the dependencies that would always be one of the first things that I would add to any project I start. But I could no longer justify it in the case of Home Assistant. Even with dead tree shaking it was not worth including it. Yes, they support a lot of edge cases but those were not relevant to my use case. And standalone lodash packages are [still huge][lodash.range]. The only thing that I couldn’t replace with a few lines of my own code was debounce. However I found [a 40 line replacement][debounce].
|
||
|
||
### <a class='title-link' name='replace-momentjs-with-fecha' href='#replace-momentjs-with-fecha'></a> Replace moment.js with Fecha
|
||
|
||
Moment.js is one of those power libraries. It is able to handle any date problem that you can throw at it. But this obviously comes at the cost of size. [Fecha] is a date formatting library at ~8% the size of moment.js (only 4.7kb pre-gzip). The only thing that it does not contain is date manipulation, which was something that was not being used.
|
||
|
||
# <a class='title-link' name='use-service-worker-to-instantly-load-the-app' href='#use-service-worker-to-instantly-load-the-app'></a> Use Service worker to instantly load the app
|
||
|
||
Using a service worker we’re able to store all app components and core javascript in the browser. This means that after their first visit, the browser will only have to go to the network to fetch the latest data from the server.
|
||
|
||
Creating a service worker is easy using [sw-precache], a service worker generation tool.
|
||
|
||
When a browser does not support service workers, Home Assistant will serve fingerprinted assets that are aggressively cached. Only when the content changes will the client redownload the asset.
|
||
|
||
Using fingerprinting with sw-precache required jumping through a few hoops. [The final build script can be found here.][build-sw]
|
||
|
||
# <a class='title-link' name='make-it-feel-fast' href='#make-it-feel-fast'></a> Make it feel fast
|
||
|
||
This one is more psychological: no one likes staring at a white screen because white screens are ambiguous: are we loading something, is there a crappy connection or maybe even a script error? That’s why it is very important to render something on the screen to show that the rest is being loaded, and as quickly as possible.
|
||
|
||
The Home Assistant landing page contains just enough CSS and HTML to render the loading screen minus the animations.
|
||
|
||
Now that the app is fast enough, I might swap out moving from a lite loading screen to drawing an empty toolbar. This makes it look like the UI is almost there.
|
||
|
||
# <a class='title-link' name='using-a-framework-build-on-web-standards' href='#using-a-framework-build-on-web-standards'></a> Using a framework build on web standards
|
||
|
||
_I left this to the end of the list, mainly because I had no influence on this. Polymer just happened to ship an update while I was optimizing the application which gave a big boost to the loading time._
|
||
|
||
By using Polymer we have the ability to use tomorrow’s web standards today. This is powered by polyfills. A polyfill will use JavaScript to simulate the behavior that the web standard would have taken care of. As browsers progress, more work can move from the polyfills back to the browsers. This is great because browsers will be able to optimize the work better and thus be faster.
|
||
|
||
Polymer 1.6 was introduced at the end of June and allowed the app to take advantage of native [CSS variables][css-vars] in Chrome and Firefox. It also introduced lazy registration. Both greatly sped up our loading times.
|
||
|
||
# <a class='title-link' name='future-optimizations' href='#future-optimizations'></a> Future optimizations
|
||
|
||
A lot of optimizations have been applied but this journey will never be over. There are still a lot of opportunities to make things even faster. Some ideas that are on my list to explore:
|
||
|
||
- Use shadow DOM instead of shady DOM polyfill.
|
||
- Use [closure compiler][closure] to optimize the JavaScript.
|
||
- Reduce the number of icons that are loaded.
|
||
- Embed initial API response in served page if not using a service worker.
|
||
- Reduce size of initial bundle by moving out all things that are not visible for initial paint. For example the dialogs that show more info about entities.
|
||
- Prefetch the other pages using `<link rel="preload" …>`
|
||
|
||
[demo]: https://home-assistant.io/demo
|
||
[hap]: https://github.com/home-assistant/home-assistant-polymer
|
||
[mantra]: https://www.youtube.com/watch?v=zfQoleQEa4w&feature=youtu.be&t=1380
|
||
[sw-precache]: https://github.com/GoogleChrome/sw-precache
|
||
[hydrolysis]: https://github.com/Polymer/hydrolysis
|
||
[hajs]: https://github.com/home-assistant/home-assistant-js
|
||
[es2015-arch]: https://github.com/home-assistant/home-assistant-polymer/wiki/Using-Polymer-with-ES2015,-Babel-and-NPM
|
||
[NuclearJS]: https://optimizely.github.io/nuclear-js/
|
||
[ImmutableJS]: https://facebook.github.io/immutable-js/
|
||
[Polymer]: https://www.polymer-project.org/
|
||
[build-html]: https://github.com/home-assistant/home-assistant-polymer/blob/master/script/vulcanize.js
|
||
[Webpack]: https://webpack.github.io/
|
||
[Rollup]: http://rollupjs.org/
|
||
[lodash.range]: https://github.com/lodash/lodash/blob/3.1.7-npm-packages/lodash.range/index.js
|
||
[debounce]: https://github.com/component/debounce
|
||
[Fecha]: https://github.com/taylorhakes/fecha
|
||
[build-sw]: https://github.com/home-assistant/home-assistant-polymer/blob/master/script/sw-precache.js
|
||
[css-vars]: https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_variables
|
||
[closure]: https://developers.google.com/closure/compiler/]]></content>
|
||
</entry>
|
||
|
||
</feed>
|