Raynos

10 ms·

1.
by Raynos 3y ago
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
2.
by Raynos 4y 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 ar
3.
by Raynos 12y 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 fo
4.
by Raynos 12y ago
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
5.
by Raynos 12y 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 s
6.
by Raynos 12y 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 a
7.
by Raynos 12y ago
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` modul
8.
Examplifier: Turn bland source code into interactive demos(raynos.github.com)
6 points by Raynos 14y ago|0 comments
9.
Distributed-map: A distributed data store in the browser(github.com)
1 points by Raynos 14y ago|0 comments
10.
StreamServer: A stream server in your browser(colingo.github.com)
6 points by Raynos 14y ago|1 comments
11.
by Raynos 14y ago
"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 share
12.
by Raynos 14y ago
In a medium sized web application, 50-70% of server-side code can be re-used verbatim between server and client.
13.
by Raynos 14y ago
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.
14.
by Raynos 14y ago
> Please never, ever write libraries that are shared with other developers. FTFY
15.
by Raynos 14y ago
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 c
16.
by Raynos 14y ago
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.
17.
by Raynos 14y ago
Maybe you should take your opinions about not using client-side code back to 1998
18.
by Raynos 14y ago
Agreed, the codebase is a mess. The ideas are nice, the implementation is absolutely horrible.
19.
by Raynos 15y ago
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 m
20.
by Raynos 15y ago
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.
21.
by Raynos 15y ago
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
22.
by Raynos 15y ago
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 f
23.
by Raynos 15y ago
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.a
24.
by Raynos 15y ago
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()
25.
Improving EcmaScript5 OO with sugar(raynos.org)
16 points by Raynos 15y ago|12 comments
26.
by Raynos 15y ago
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 co
27.
by Raynos 15y ago
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.
28.
by Raynos 15y ago
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
29.
by Raynos 15y ago
Is Java faster then JavaScript? Yes. Is it easier to write performant code with node.js vs Java Async IO? Subjective.
30.
by Raynos 15y ago
3. child_process API and bolting C++ extensions onto node allow you to do this.

More ›