Raynos

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.

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.

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.

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

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`

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.

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.

"medium" means I don't have personal experience of how the percentage scales to large applications.

as for sharing: data sources, domain models, utilities and templates can be shared. its the io handling (HTTP and dom) that can not be shared.

In a medium sized web application, 50-70% of server-side code can be re-used verbatim between server and client.

I highly recommend you consider using mocha with the TDD interface rather then nodeunit.

[I recently evaluated different node testing libraries](https://gist.github.com/b0382064a4ddac608b8c), which may help with your own evaluation.

> Please never, ever write libraries that are shared with other developers.

FTFY

2, 3, 4 should not be done.

There is no value in using any of those features.

As mentioned, 5 is not a thing. That's spec politics, you shouldn't be doing any of that.

As for 1, well that's a whole other argument, and it's an opinion. You choose one, nobody cares what you choose.

Why don't we spend effort on building an ES:Harmony -> ES3 compiler rather then a CoffeeScript -> ES3 compiler.

It's more worthwhile future facing project.

Maybe you should take your opinions about not using client-side code back to 1998

Agreed, the codebase is a mess.

The ideas are nice, the implementation is absolutely horrible.

the method fails for the exact same reason.

If a single method calls a super method and that method calls another super method then it fails.

    Object.getPrototypeOf(this).method

Always have one value and only one value, calling it more then once leads to infinite recursion.

For the record, I didn't write this library because I thought I could do it better.

I wrote it because I didn't know about these other utilities / tools.

    Object.getPrototypeOf(Child).constructor.apply(this, arguments);

Works, but is even more verbose. However if you use Object.getPrototypeOf on this you fail the recursive problem in nest super calls. Read the stackoverflow euestion

What your showing is ES3 OO sugar.

The problem I have is that the notion of a constructor function goes against prototypical OO.

In prototypical OO we just have objects and objects inherit from objects. there is no notion of a constructor function.

Also note that pd.make returns an object rather then a function.

It's simply a programming style I like, to think of my "class" object not as the constructor function but as the prototype object.

Not to mention that `x.prototype.foo = ...` is ugly.

    var Animal = {
        constructor: function () {
            this.legs = legs; 
        },
        speed: function () {
            return this.legs * 10;    
        }
    };
    
    var Dog = pd.make(Animal, {
        constructor: function (name) {
            Animal.constructor.call(this, 4);
            this.name = name;
        },
        speed: function () {
            return Animal.speed.call(this) * 2;    
        }
    });

super is a nightmare to emulate and get "right". It has a bunch of weird edge cases you don't really want to think about.

I promote code like

    var Cat = Object.make(Animal, {
      constructor: function() {
        Animal.constructor.apply(this, arguments);
        ...
      },
      walk: function() {
        Animal.walk.apply(this, arguments);
        ...
      }
    });

Now compare:

- Animal.walk.apply(this, arguments);

- this.super.apply(this, arguments);

- this.super.walk.apply(this, arguments);

Using super doesn't fix verbosity, it only fixes hard coupling of Child class name to Super class name.

For the complexities, edge cases and performance penalties a super implementation gives, it's simply not worth fixing this hard coupling.

If you know of a super implementation that _just works_ please [Leave an answer on StackOverflow](http://stackoverflow.com/questions/8032566/emulate-super-in-...)

You need all three I'm afraid.

We need an easy way to mixin/extend objects.

   var obj = protoObj <| mixin({ ... properties ... }, mixinA);

We also need a solid way to create instances.

   object.create(obj);
   obj.constructor();

is just too verbose. There is some talk around making `new` work with object exemplars which would be great.

When I say the speed of C. I'm really comparing various language X compilers to the GCC compiler under the assumption that the GCC compiler is the best.

No it's not a magical constant but I think for a baseline comparison "how close your compiler X is to GCC" is a fair thing to compare.

I also doubt V8 or spidermonkey can get better then GCC _on average_

It's pretty well known that Java hovers around 1.1x the speed of C where as JS hovers around 2-3x the speed of C.

So yes Java is faster.

That's the whole point. Most requests have the same order of magnitude.

If you have two sets of requests that have different orders of magnitude then put these two sets on their own node worker process behind your load balancer.

As long as you send your requests to the worker process that handles requests of a similar order of magnitude you will never have the faster requests being stuck behind slower requests problem.

Is Java faster then JavaScript? Yes.

Is it easier to write performant code with node.js vs Java Async IO? Subjective.

3. child_process API and bolting C++ extensions onto node allow you to do this.