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.
I use similar pattern myself. Was curious if the OP is using some other, like for instance splitting the struct into two (im/mutable) and then passing them around, or what.
BTW kudos on zanzibar. Love the tech and the code).
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.
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.
There is interaction occurring with the DOM in both benchmarks.
The way that the Backbone TodoView is designed does not take into account the possibility of a user adding 100 items using the dom within a tight loop. Probably because such a use case is impossible outside of this type of benchmark. By doing so the Backbone implementation ends up performing a lot of unnecessary renders. Therefore as far as Backbone performance is concerned this benchmark is not indicative of any real world scenario.
Just to re-iterate; when you're loading a set of todos from your local storage to display when the user first opens the page, you would not populate the "new todo" input box and fake an enter event for each item that you want to add. Instead you would reset the Backbone.Collection with a list of your new todos (go through the interface). That's basically the change I made to the benchmark. Sorry if it wasn't clear.
Running your perf test, I consistently get Backbone being the fastest, Angular the slowest, and the projects using Virtual DOM approach somewhere in the middle. Is that expected?
http://evancz.github.io/todomvc-perf-comparison/
edit: I was running the original test instead of your fork.
This seems similar to a module I wrote called [html-delegator][1].
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.
- 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.
I have a similar frustration with React. The source code is very hard to read our follow.
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.
Is there a single-file version of virtual dom available for download? I am not finding any instructions in the repo on how to build it. Also, why does it have so many files in the first place?
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.
Well, whatever "medium sized" means, I work on a high-traffic Web application that reuses 0% of code from the client; in almost everything I've worked on, I've found reuse between client and server nearly impossible, enough that they're almost always segregated repositories. There's an argument for models existing on both sides (which is reiterated below), but I have a hard time seeing models as 50-70% of any application.
Just not my experience that this is the case. Though I might be old-fashioned.
I've recently been working with a team that is developing a content management system for which the display side of things (responsible for routing requests to models and views, fetching model content, rendering, etc.) is about 500 lines of non-comment CoffeeScript code.
Nearly 100% of the server-side code is re-used on the client, and perhaps 80% of the (non-library) client-side code is shared with the server.
In this case the exceptions are:
- Things like HTTP-level request handling and reading from local files rather than over HTTP are used on the server-side only.
- Things like DOM-manipulation and interacting with browser events are used on the client-side only.
I wonder if a significant factor may be how much functionality you're actually replicating on both the client and server. In our case, browser-permitting, the entire display engine runs equally well on the client or on the server. If we had a lot of JQuery kind of stuff happening in the client-side JavaScript the ratios might be a little different, but "also-run-the-app-on-the-client" is a good example of a use case that leads to a lot of reuse of the server side code.
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.