Raynos

Joined 15 years ago

Karma

Submissions

Member since

May 21

Recent submissions

I wrote a static config class that reads configuration for the entire app / server from a JSON or YAML file ( https://github.com/uber/zanzibar/blob/master/runtime/static_... ).

Once you've loaded it and mutated it for testing purposes or for copying from ENV vars into the config, you can then freeze it before passing it down to all your app level code.

Having this wrapper object that can be frozen and has a `get()` method to read JSON like data make it effectively not mutable.

Comment · 3 years ago

I’m moving locations a lot myself too. I’ve found deel / remote is not great because it tethers you to the country you started in.

For my situation setting up my own us llc and contracting/consulting through it means I can move around. Also the us llc onboards cleanly for any companies using gusto and for others I send a W9 that they know how to handle.

Comment · 12 years ago

In all javascript apps the part that is slow is the DOM, not the javascript interface.

This benchmark was taken from the webkit source code then forked into http://vuejs.org/perf/ then forked to include mercury then forked again to include elm.

Neither elm nor mercury came up with this benchmark and just added themself to it.

What this benchmarks shows is that async rendering is really fast. Mercury, vue & elm all use async rendering where DOM effects are batched and only applied once.

A better, close to real user experience benchmark would be one using mousemove since that's an event that can happen multiple times per frame.

Comment · 12 years ago

The separation of thing that emits named event and listener is a good idea.

I Actually moved away from the HTML attribute DSL and started putting named events in my virtual dom instead (using [mercury][2])

The important part of this approach that is not shown in js action is to ensure you emit data structures instead of dom event objects to the listeners.

  [1]: https://github.com/Raynos/html-delegator/blob/master/README.md
  [2]: https://github.com/Raynos/mercury

Comment · 12 years ago

I opened this PR on virtual-dom ( https://github.com/Matt-Esch/virtual-dom/pull/67 ) to get a single file version into the git repo.

It has many folders because the `vtree`, `vdom` and `h` are fundamentally seperate concepts.

Again each one is seperated into it's own files, this allows you to just require the `is-x` functions or the `diff` function alone without having to depend on the entire implementation.

It's also easier to maintain code if it's not one big file.

There are plans to break vtree & vdom out

- https://github.com/Matt-Esch/vtree - https://github.com/Matt-Esch/vdom

Note `vdom` is an implementation detail, we could also write `vcanvas` or `vwebgl`

Comment · 12 years ago

I've been building a FP style framework very similar to OM & Elm in plain javascript ( https://github.com/Raynos/mercury ).

It has some of the core features

- immutable data - immutable vdom - global state atom, no hidden local state. - no manual DOM manipulation code (read or write). - a single top down flow of data from input to output - Events and Signals from FRP that can be manipulated using pure higher order functions.

etc.

As a bonus it's very modular, so if it doesn't fit your needs at least some subset of it will.

Comment · 12 years ago

An ideal "barebones" virtual dom library looks like https://github.com/Matt-Esch/virtual-dom . The `virtual-dom` module was build out of frustration with the readability of react source code and is the minimal modular subset.

I've also built a small framework on top `virtual-dom` to add in essentials like immutable state and event handling ( https://github.com/Raynos/mercury ). Whilst mercury might not be the best way to structure apps, it's an approach that is getting me far and I'm drawing strong inspiration from FRP and FP systems like Elm and om.