Commit 5fb2146b authored by Tanner Doshier's avatar Tanner Doshier
Browse files

Add some pages and posts

parent 019ac030
......@@ -8,3 +8,4 @@ I'm interested in functional programming in general and Haskell in particular.
I have a BS in Computer Engineering with minors in both math and physics.
If you want to get in touch, email is your best bet: `<my pseudonym>@gmail.com`
(no brackets)
---
title: Lenovo Thinkpad X230
---
My current main computer is a Thinkpad X230 purchased in 2013. I bought it
factory refurbished with 4GB RAM and some HDD (250GB I think). My focus when
buying the computer (since I was buying refurbished I couldn't just build to my
wants) was on getting the IPS screen and the i5 processor, the other things
could be replaced easily. And they were, swapped that 4GB RAM for 16GB and that
HDD for an SSD I had (an Intel X-25M 80GB SSD).
# Screen
Made sure to the IPS version for the better viewing angles and such. It gets
really bright if you want it to. Resolution is under-whelming, but it's been
ok. I have noticed over the years, some hot spots developing. Now at some point
I think someone had pushed down from the back of the screen/top of the computer
and maybe they are a result of that, couldn't tell you specifically. Most of
the time they aren't a bother, but once I notice them, I'll keep noticing them
for a while. I've also noticed a tendency for burn-in/ghosting to happen, e.g.,
I'll switch work spaces and see a faint outline of the other applications
toolbar for a short while. Again, couldn't tell you exactly when I started
noticing this, but I have.
All and all, the screen is a bit of a disappointment. I think Lenovo have
stepped up their game on newer models and that's good, because they need to.
# Keyboard
I went with the X230 over say the X220 in part because of the chiclet keyboard
for a couple reasons. One, I generally like chiclet keyboards, both in
appearance and functionally (I feel like the void space between keys helps).
Two, it is the direction Thinkpad keyboards were going so I was gonna have to
get used to them eventually if I ever wanted to buy a new computer (I was not
under the delusion that Lenovo would wake up and think the new keyboard design
was a terrible mistake and revert to the old style).
I have no experience with the old style keyboard so I can't compare there, but
I like the keyboard on the X230 well enough. I have two issues with it though.
One, and the biggest one, the placement of the `PrtSc` button. It's just in a
really stupid place. Particularly for Linux users who generally use
`Ctrl+Alt+<an arrow key>` to switch workspaces since the `PrtSc` is sandwiched
between the right `Ctrl` and `Alt`. Before I changed the functionality of the
button in the OS I would take so many inadvertent screen shots, it was really
annoying. The second issue, is the placement/order of the `Fn` and `Ctrl`
buttons on the left side; mainly, they are in the exact wrong order. Lenovo
provides a BIOS toggle which switches their behavior (and I enabled it
immediately), but still annoying for the markings to be wrong and for my `Ctrl`
key to be smaller than my `Fn` key since I use the `Ctrl` key a lot more. Now I
generally remap `CapsLock` to `Ctrl` in the OS, so it's not a crazy big deal,
but sometimes my muscle memory wants to `Ctrl-C` something and it reaches for
the bottom left corner.
Besides those things, no complaints, the keyboard does its job.
# The make things work bits
I've been happy with the performance of the Intel® Core™ i5-3320M CPU. The
integrated Intel HD Graphics 4000 graphics do a great job as well. I can do
some light gaming (on the admittedly low resolution screen) just fine.
# Wrap-up
I've been happy with my purchase overall and I'll probably look to Lenovo for
my next machine when the time comes. I do wish I could by a OS-less or
Linux-pre-loaded (like Dell's Developer Editions) laptop from them though and
skip the Microsoft tax.
---
title: Uses This
toc: on
---
There's a neat series of interviews at [usesthis.com](http://usesthis.com/) and
in generally I like seeing what other people use to do stuff. So here's some of
mine.
# Hardware
* [Lenovo Thinkpad X230](/thinkpad-x230/)
* Intel X-25M 80GB SSD (from 2010, currently in X230)
* Sennheiser HD 555 w/ a right angle 1/4" to 3.5mm adapter so I don't break the
port on my laptop (as the bundled straight adapter makes the thing stick out
and sag)
* Nexus 4 w/ a Ringke SLIM case to keep everything from being rubbed/scratched
constantly and to add a bit of texture to the back since the glass is rather
slippery
# Software
* Vim
* tmux
* make (for things I should probably use shell scripts for)
* [KeePassX](https://www.keepassx.org/) and
[KeePassDroid](http://www.keepassdroid.com/) to manage my passwords
* Firefox (on both the desktop and Android)
* Fedora for my development machine(s), though I'm evaluating NixOS as well
* Tarsnap
# Writing Stuff
## Pencils
* TWSBI Precision w/Retractable tip (in 0.5mm) - for the backpack/pocket/travel
* Alvin Draft/Matic Pencil (in 0.5mm) - for home
* Pentel PS535 - my go-to pencil in college
## Pens
* Lamy Safari (in Charcoal with 1.1mm and EF nib)
* A few Reform 1745s
* Parker 51 Aeromatic (grey body/silver cap)
* Noodlers Ahab (in Amazon Pearl)
## Ink
* Noodler's Sequoia Green
* Noodler's Cactus Green
* Noodler's Bulletproof Black
* Aurora black
## Notebooks
* Leuchtturm 1917 (dotted)
* Computer Paper + clipboard
# Food
I eat a mostly-vegan diet (eggs slip in here and there) as well as being gluten
and lactose intolerant. The latter is taken care of by the vegan part, but
avoiding gluten does complicate my diet a bit. I also try to stay away from
soy, which is a further complication, though I've loosened that restriction
lately. Inside those constraints though, I'm not picky, I'll try just about
anything that I can. Indeed, becoming (mostly) vegan has exposed me to a lot of
different foods that I really enjoy.
While it has gotten easier to find or make vegetarian/vegan dishes at most
places I still end up cooking for myself a lot, which is good honestly. I enjoy
cooking, it's generally cheaper to cook for yourself, you know exactly what is
going into the dish (important given the number of ingredients I wish to
avoid), and I have a few places I look to when trying to come up with
something to eat:
* [The Gluten Free Vegan](http://www.theglutenfreevegan.com/) - recipes can be
a bit involved or use fancy/harder to find/more expensive ingredients
* [Budget Bytes](http://www.budgetbytes.com/) - love the simplicity of the
meals, very practical
* [Oh My Veggies](http://ohmyveggies.com/) - collects posts from a lot of
places, weekly meal plans are also nice (though they don't often completely
work for me)
---
title: Wishlist, of sorts
toc: on
---
So I have a [page about what I already use](/uses-this/), but there's plenty
of other tools I'd like at some point.
# Computer
My ideal next computer would have the following specs:
* Two user upgradeable RAM slots (I need my 16GB)
* M.2 (supporting PCIe NVMe) SSD (user upgradeable)
* USB Type-C connectors exclusively for power and data connections (though
full-sized USB 3.1 ports instead would be fine too)
* Mini DisplayPort/Thunderbolt
* No VGA port, use that space for something more useful
* HD IPS Display ideally around 13-inches, doesn't necessarily have to be
at least 2560x1600...but yes it does (honestly though, 1920x1080 would
probably be ok too); I'd prefer a 16:10 ratio, but I'll take what I can get
* Intel Iris Pro graphics
* 802.11ac (and all the lesser standards as well) and Bluetooth 4.0 (with LE
support)
I think the second half of 2015 or first half of 2016 is about as early as I
can hope for something like this to be achieved. This is mostly because
[Skylake](https://en.wikipedia.org/wiki/Skylake_%28microarchitecture%29) will
likely retire VGA support, add USB 3.1 (with Type-C) support natively, and
bring much better graphics. Also, I believe Dell has exclusive use of the Sharp
screen tech for what they call their "infinity display" until the end of 2015
and while not necessary (I'm a touch wary about having such a large, flush,
edge-to-edge glass screen) I definitely would like slimmer bezels and more
screen space for that glorious resolution to be put to use. I don't mind have
to use dongles for legacy interface support or really even RJ45 (I don't
use it very often).
Of course, a computer isn't merely the sum of it's specs, how they are put
together matters a lot too. All the best tech in a crappy plastic case would
suck.
I'm hoping the Lenovo Thinkpad X260 will hit a majority of these points for me.
I'm not holding my breath for it though. Might have to look at the Thinkpad T
series, though they are a bit bigger than I'd like and tend to be conservative
with ports and stuff. The X1 (2015/3rd gen) is pretty good, but like all the
"Ultrabooks" almost everything is soldered in (particularly the battery and
RAM, two of the main things I'd want to be able to swap out whenever I want)
and it's still this gen/last gen. The new Macbooks also hit a number of the
wants, but I'm not gonna buy anything from Apple. The ultrabooks class of
computers in general put to much emphasis on thinness and not enough on
usability for me. I'd take a 3mm thicker laptop if it meant better battery
life, user upgradeable parts and/or stronger CPU/GPU everyday of the week.
# Keyboards
## ErgoDox
[Homepage](http://ergodox.org/)
[Massdrop](https://www.massdrop.com/buy/ergodox)
[AnandTech review](http://www.anandtech.com/show/7245/ergodox-review-an-ergonomic-mechanical-keyboard-via-massdrop)
I liked the ErgoDox from the second I saw it.
If I buy one it will probably be through the Massdrop group buys, as I don't
feel like hunting down and ordering all the parts myself (not to mention
getting the PCB printed). The Massdrops so far have been pretty slow (e.g. one
finished in November 2014, people only started receiving things in Feburary
2015), but beats having to deal with it all myself.
Will likely go with Cherry MX Blues with some o-rings added, I like the
tactile and clicky feedback and the o-rings take out most of the harsh noise.
## Axios
[Homepage](http://axios.io/)
[geekhack.org discussion](https://geekhack.org/index.php?topic=44940.0)
A kind of an ErgoDox 2.0 or ErgoDox on steroids. AcidFire is putting together a
really solid keyboard, very well thought out.
Advantages over the ErgoDox:
* Completely open source (controller is ATMEGA32u4 with an open source
bootloader instead of Teensy like the ErgoDox)
* Adjustable
* Expandable (add-on modules for wireless, LED controller, etc.)
## Kinesis Advantage
The current Kinesis Advantage has some pros and cons compared to the above
keyboards.
Advantages:
* Cupped key arrangement, seems like this would be more comfortable than flat
things
Disadvantages:
* Build quality - I've heard it's on the low side/disappointing
* Size - really wish is was streamlined and actually split into two parts, or
at least made use of the huge void space between the two cups
Now I've read that Kinesis is working on a new, better, Advantage Pro model
which might address many of the issues the current iteration has, which is
great news. Makes me more likely to buy one in the future if it turns out to be
true.
## TextBlade
[Homepage](https://waytools.com/)
Kinda slick looking and compact while maybe not being terrible. If it turns out
to be any good, it'd be pretty nice to just have when mobile.
# Pencils
* I'll probably get something in the Uni Kuru Toga series at some point, I had
one a long time ago, but the mechanism got jammed/broken, so I'm hoping the
newer models are improved a bit
---
title: An Opinionated Overview of JavaScript Stuff (early 2015)
meta-description: A look at modern JavaScript tools
tags: JavaScript
toc: on
---
The next major version of a product at work is probably a rich/fat web client
talking to a REST API, like many things these days. We are currently at the
beginning of this transition. There is one small sub-system that has been
rewritten in Angular (1.3 at time of writing) utilizing a legacy AJAX system we
have, but before getting too much further along in our current path, I felt it
was probably a good idea to survey the current landscape of web client
frameworks/libraries/tools and get some stuff down on (digital) paper.
Now the discussion here is going to be biased by a couple things:
1. My own personal preferences; I like strong statically typed, functional
languages (e.g., Haskell)
2. The needs at work. For the work situation, we need (in my opinion) something
that is 'simple', not necessarily a shallow learning curve, but rather an
execution model that you can understand, easy debugging and help making sure
things don't break. Another factor is the development team at work is pretty
small, a couple to a few developers at any given time, so one person needs
to be able to accomplish a lot and maintain the product over time; we need
something expressive.
3. I haven't actually used most of these tools. I'm making judgments based on
the project's documentation and the chatter on other sites (HN, Reddit,
etc.) from people who *have* used them.
It should go without saying, but the contents of my personal blog are my own
opinions and in no way represent the opinions of my employer. Furthermore, I in
no way intended or wish to misrepresent any of the tools in this post, if you
find an issue, please [get in touch](/about/).
[AngularJS Homepage]: https://angularjs.org/
[Angular 2 Hompage]: https://angular.io/
[Flux Homepage]: http://facebook.github.io/flux/
[React Homepage]: https://facebook.github.io/react/
[Mercury Homepage]: https://github.com/Raynos/mercury
[Typescript Homepage]: http://www.typescriptlang.org/
[Flow Homepage]: http://flowtype.org/
[Elm Homepage]: http://elm-lang.org/
[Mithril Homepage]: https://lhorie.github.io/mithril/index.html
[AtScript Homepage]: https://docs.google.com/document/d/11YUzC-1d0V1-Q3V0fQ7KSit97HnZoKVygDxpWzEYW0U/mobilebasic?pli=1&viewopt=127
[Sweet.js Homepage]: http://sweetjs.org/
[Bacon.js Homepage]: https://baconjs.github.io/
[RxJS Homepage]: https://reactive-extensions.github.io/RxJS/
[CoffeeScript Homepage]: http://coffeescript.org/
# Plain JS solutions
## AngularJS 1.x
[Homepage][AngularJS Homepage]
AngularJS is a sophisticated framework for building web applications which
emphasizes a bi-directional dataflow and testing. It's one of the oldest of the
'new' JS libraries/frameworks and as such, has some inertia to it, though I
feel it really only started picking up steam in the past couple of years.
### Pros
* Already working for a few things at work
* Lots of drop in components
* Two-way data binding
* Backed by Google
* Emphasis on testability
* Fairly straightforward design patterns to follow (and [published guidelines](https://blog.angularjs.org/2014/02/an-angularjs-style-guide-and-best.html?_escaped_fragment_=))
### Cons
* Can be complicated and fragile (we have already seen this at work)
* Two-way data binding
* Likely large and incompatible 2.x coming within the next year, maybe with
migration tools, but likely to be a very different framework (i.e.
knowledge/experience gained on 1.x may not directly translate into
productivity with 2.x)
* Can have performance issues
* Is depending on browsers implementing native code (`Object.observe`) to
alleviate some of it's problems
* See [this presentation on `Object.observe`](https://markdalgleish.github.io/presentation-a-state-of-change-object-observe/)
## Flux + React
[Flux Homepage]
• [React Homepage]
One of the newer kids on the block, React is 'View' layer for web applications
which utilizes a 'Virtual DOM' to build up and swap out parts of the DOM
efficiently. Flux is an application architecture (as well as the name of
Facebook's implementation of the Flux architecture) which emphasizes a
uni-directional dataflow which works well with React.
### Pros
* One-way dataflow
* Generally more performant (compared to AngularJS)
* Backed by Facebook
* Flexibility in implementation/architecture, Flux provides some structure
### Cons
* More immature ecosystem (compare to AngularJS)
* No single best-practice/do-this architecture to follow, though Flux provides
some structure
### Misc
* While one may end up having to roll their own solutions to some things,
[Yahoo is rewriting their mail app with React and are open-sourcing a number of library](https://facebook.github.io/react/blog/2014/10/17/community-roundup-23.html#yahoo)
in the process so the ecosystem is likely to be continue growing with
industrial quality components
* In general, the [React blog](https://facebook.github.io/react/blog/) is worth
reading, particularly the community round-up posts
### More info
Tools are available built around these components:
* [Marty.js](http://martyjs.org/), [HN Discussion](https://news.ycombinator.com/item?id=8923053)
* [Fluxxor](http://fluxxor.com/)
* [RefluxJS](https://github.com/spoike/refluxjs)
* [ReactFlux](https://github.com/kjda/ReactFlux)
## Mercury
[Homepage][Mercury Homepage]
### Pros
* Extremely modular, can use which parts one wants/needs
* Generally very good performance (in contention for title of highest
performing library currently available I'd say)
* Flexibility in implementation/architecture
### Cons
* Extremely modular
* No single best-practice/do-this architecture to follow
* No big corporate backing?
## Mithril
[Homepage][Mithril Homepage]
Opposite end of the spectrum from [Mercury] with regards to modularity: Mithril
is one file. It's goal is to be small and simple, both in the code itself and
the cognitive load required to use it.
### Pros
* Very small and 'simple'
* Very good performance, up there with [Mercury]
* Flexibility in implementation/architecture
### Cons
* I feel it could be a lot of boilerplate/lack of convenient functionality
* No single best-practice/do-this architecture to follow, there are some
official suggestions on how to structure an app, but you would largely be
developing our your way to structure the code
* No big corporate backing?
# Typed JS tools
Plain JS will probably one day get type annotations[^eich-comment] likely based
on whatever syntax/semantics Typescript and Flow can come to agree on since
these are the two working tools (that I know of) that have the types sprinkled
in otherwise vanilla JS syntax.
[^eich-comment]: <https://github.com/mozilla/sweet.js/issues/393#issuecomment-56405997>
## Typescript
[Homepage][Typescript Homepage]
TypeScript is a superset of JS that gives developers a more familiar OOP syntax
to use that compiles down to plain JS. It was one of the first typed JS
supersets and also brings in ES6/ES 2015-like features (e.g., modules and
classes). The forthcoming 1.5 release will bring the compiler to almost
complete parity with ES6/ES 2015 and the 1.6 release will start pulling in ES7
features. It's one of the best ways to get the JS-of-tomorrow today.
## Flow
[Homepage][Flow Homepage]
> A static type checker for JavaScript
Flow is practically brand new, just open sourced at the end of 2014, though
Facebook has been using it internally for a while. All it does is type checking
(unlike TypeScript) using annotations similar to TypeScript. From what I've
seen Flow's type system is a bit better and more expressive, though TypeScript
is catching up (e.g. TypeScript 1.4 will include Union Types and Type Aliases,
which Flow already supports).
The downside is that the code Flow type-checks has to be pretty much plain JS
(with type annotations) so you can't really combine it with other tools (like
Sweet.js) unless those other tools will preserve the annotations when
transforming the code. One could potentially work around this with something
like [flotate](https://github.com/jareware/flotate) (some of it's [rationale
discussed
here](https://github.com/facebook/flow/issues/3#issuecomment-69012810)) as long
as the other tools preserve comments. Some tools (like [Babel]) already support
Flow and I imagine that broader community support for type annotations will
grow quickly.
## Elm
[Homepage][Elm Homepage]
When referring to Elm, generally I mean Elm + the elm-html library (which is a
virtual-dom library similar to React)
### Pros
* "Better" language than JS to work with
* Many of the same benefits of Flux + React or Mercury
* Interoperable with plain JS (via a language feature called ports)
* Can have even better performance than React because of language features (immutable data structures, optional lazy evaluations, etc.)
* Don't have to deal with npm and bower
* [A natural way to structure applications](https://github.com/evancz/elm-architecture-tutorial#the-elm-architecture)
### Cons
* Like React, more immature ecosystem
* No big corporate backing?
## PureScript
[PureScript](http://www.purescript.org/)
> PureScript is a small strongly typed programming language that compiles to
> JavaScript.
Taking many cues from Haskell, but making them fit in the JS world (like
strict-by-default evaluation), PureScript compiles down to a plain JS with no
runtime (unlike Elm). It has existing bindings to things like
[React](https://github.com/purescript-contrib/purescript-react) and
[Angular](https://github.com/purescript-contrib/purescript-angular), though
they are both in the alpha/experimental stages. They also push against some of
the functional features of PureScript so using something lower-level and more
friendly to immutable data like
[virtual-dom](https://github.com/purescript-contrib/purescript-virtual-dom) is
probably a better approach.
Paired with something like the [signal
library](https://github.com/bodil/purescript-signal) and you have a virtual-dom
FRP implementation to play with.
## Other Haskell Stuff
There's a lot of awesome stuff going in the Haskell world to improve JS
development, mostly in the form of Haskell-to-JavaScript compilers. As of
today, most of it probably isn't ready for prime time/big stuff, but is
improving and I expect things to get a lot better here quickly.
See [this
post](http://blog.jenkster.com/2015/02/a-brief-and-partial-review-of-haskell-in-the-browser.html)
for a further discussion of some of these options and [the reddit
post](http://www.reddit.com/r/haskell/comments/2umqfr/a_brief_and_partial_review_of_haskell_in_the/)
has some good discussion.
### Full Haskell
* [GHCJS](https://github.com/ghcjs/ghcjs) - Version of GHC that emits JS
instead of native code, compile *any* Haskell to JS
* [Haste](http://haste-lang.org/) - Compile *almost any* Haskell to JS
### Haskell interop
* [Fay](https://github.com/faylang/fay/wiki)
### Other
* Inferno (formerly SJS) - type inference for JS
* [Introduction post](https://noamlewis.wordpress.com/2015/01/20/introducing-sjs-a-type-inferer-and-checker-for-javascript/)
* [Reddit discussion](http://www.reddit.com/r/haskell/comments/2szt1u/introducing_sjs_a_type_inferer_and_checker_for/)
# Other JS Language Tools
## Sweet.js
[Homepage][Sweet.js Homepage]
This is a macro system for JS. It would probably be extremely useful in
cutting down boilerplate if one chooses to use plain JS-of-today for a
project. The biggest downside with Sweet.js is that it doesn't (yet) support
type annotations so doesn't integrate super nicely with the other
static-analysis/type-checking tools.
## Bacon.js and RxJS
[Bacon.js Homepage]
• [RxJS Homepage]
Both Bacon.js and RxJS provide "reactive" components, which, roughly speaking,
are things that have some notion of time built into them. They use different
terms, but I believe the libraries are fairly equivalent in functionally. The
[Bacon.js docs](https://baconjs.github.io/api.html#for-rxjs-users) have a bit
on their compatibility.
## Immutable and Mori
[Immutable.js Homepage](https://facebook.github.io/immutable-js/)
[Mori Homepage](https://swannodette.github.io/mori/)
Provides immutable data structures. Immutable data is great for a variety of
things and in particular in can be a big boon when working with rendering stuff
since determining if anything has changed is a cheap check.
## Babel
[Homepage](https://babeljs.io/)
Babel makes next generation JS features available now by compiling them down
into today's JS. The currently broadly supported JS lacks a lot of modern
features, this can be a great way to utilize some of them (like modules) until
the browsers/your user base catch up. Used to be called 6to5.
## CoffeeScript
[Homepage][CoffeeScript Homepage]
I mention this merely because it is somewhat popular, but I don't really
consider it an option as it doesn't bring a whole lot of important things
(namely static type checking) that the other solutions provide, it is largely
just syntax sugar.
# Everything Else
There are a bazillion other JS frameworks/tools out there that I didn't look at
closely, some linked below:
## Frameworks
* [Cycle.js](https://github.com/staltz/cycle)
* [Aurelia](http://aurelia.io/), [Blog Announcement](http://blog.durandal.io/2015/01/26/introducing-aurelia/), [HN announcement](https://news.ycombinator.com/item?id=8948665)
* [Durandal](http://durandaljs.com/)
* [Vue.js](http://vuejs.org/)
* [Enyo](http://enyojs.com/)
* [Ember.js](http://emberjs.com/)
* [RightJS](http://rightjs.org/)
## Pieces
* [Amperstand.js](http://ampersandjs.com/)
* [Backbone.js](http://backbonejs.org/)
* [Knockout](http://knockoutjs.com/)
* [Ractive.js](http://www.ractivejs.org/)
## Languages
* [Roy](http://roy.brianmckenna.org/)
* [LiveScript](http://livescript.net/)
## Other
* [Comparison of a bunch of frameworks](https://docs.google.com/spreadsheets/d/1r8rJy2Q5p5QORYKcye93UECwOlSgFL24c5fyF7dqhaM/edit?pli=1#gid=1607194899) (hint: tabs at the bottom)
# TodoMVC Benchmark
There's a TodoMVC benchmark with a variety of popular (and obscure) frameworks
here:
<http://matt-esch.github.io/mercury-perf/>
The benchmark consists of creating 100 todos, marking them as completed, and
then deleting them. It aims to give an idea of how frameworks perform under
real-world-ish conditions running idiomatic code (as opposed to
micro-benchmarks, which tend to take advantage of obscure tricks and aggressive
optimizations that sacrifice maintainability for extra speed). A more [limited
benchmark](https://evancz.github.io/todomvc-perf-comparison/), but with a
prettier graph at the end is also available; it was put together for [the blog
post announcing elm-html](http://elm-lang.org/blog/Blazing-Fast-Html.elm).
# Best Bets Today
## Flux + React + Immutable + Flow
Integrating a static analysis tool like [Flow] would be a requirement for me, but
that could be dropped if your requirements are pure JS with no build step
(and/or you subscribe to the pulling your hair out and yelling at the computer
style of debugging/refactoring; static analysis really helps people).
To see how some of this stuff plays together, see [this blog
post](http://aeflash.com/2015-02/react-tips-and-best-practices.html) which
suggests making heavy use of the
[PureRenderMixin](http://facebook.github.io/react/docs/pure-render-mixin.html)
(among other things) and generally having pure functions and immutable data.
I'd probably also want to use some JS-of-tomorrow layer as well, either using
[Babel] or swapping out [Flow] for [Typescript].
## Elm
A clean, modern language designed from the ground up to make web development
better. Immature in some ways and may not be "production ready" enough for all
cases, but well worth a look and experiment. The language is evolving fairly
quickly, so you'll need to keep up, but that's no different that most other
things in the JS world right now (^_^).
# TL;DR