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.

Raynos

4년 전discuss

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.

Raynos

12년 전discuss

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.

Raynos

12년 전discuss

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

Raynos

12년 전discuss

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`

Raynos

12년 전discuss

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.

Raynos

12년 전discuss

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.

Raynos

14년 전discuss

"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.

Raynos

14년 전discuss

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

Raynos

14년 전discuss

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.

Raynos

14년 전discuss

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

FTFY

Raynos

14년 전discuss

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.

Raynos

14년 전discuss

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.

Raynos

14년 전discuss

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

Raynos

14년 전discuss

Agreed, the codebase is a mess.

The ideas are nice, the implementation is absolutely horrible.

Raynos

15년 전discuss

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.

Raynos

15년 전discuss

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.

Raynos

15년 전discuss

    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

Raynos

15년 전discuss

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;    
        }
    });

Raynos

15년 전discuss

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-...)

Submissions

Examplifier: Turn bland source code into interactive demos

Distributed-map: A distributed data store in the browser

StreamServer: A stream server in your browser

Improving EcmaScript5 OO with sugar

What it means to be non-blocking in node.js

Doing Object Oriented JavaScript

comments