After playing around a little and realizing how limited ES5 really is, I'm open to writing this thing in 100% TypeScript. There's some caveats, though - if the schema file is loaded dynamically it'll be hard (impossible?) to add type safety without runtime type checks, and I can see that getting expensive. TypeScript almost gets in the way in this case. However, a schema compiler can be set up to emit either typescript or vanilla ES5 code; *that* could work quite well! ArrayBuffers will contain the raw data and property access/method calls will just reference indices in the array - the only *super* annoying thing about it is there's no native support for 64-bit words in JavaScript so everything has to be broken up into hi/lo 32-bit words in a Uint32Array (yuck!).
There are concerns about TypeScript being generally slower if you lean heavily on the ES6 features (https://kpdecker.github.io/six-speed/), but with proper profiling it shouldn't be hard to identify hotspots and turn them into tightly optimized code that won't be modified much by the transpiler. The speed problems come in when you heavily depend on things like arrow functions and the transpiler ends up adding extra assignments and variables you didn't expect. For what it's worth, I expect most performance concerns won't have anything to do with using ES6. I agree that the transport layer needs to be pluggable and that's the design I'm going to go for right from the start. Realistically I'm going to have a hard time designing the whole thing without a sample app to reference so *some *form of transport needs to be supported "out of the box". WebSockets feels like an easy initial target for this. Supporting window.postMessage should also be easy, and since you can pass ArrayBuffers with zero-copy (I think??) it'll be crazy fast! Speaking of sample app; I plan on writing a TodoMVC type thing in separate repos as a reference implementation (a node server and a browser client w/ React). Any thoughts on this? Should I instead try to go for something that better showcases the power of capability-based access control? A todo list where you can securely share edit/view access with others could be a fun demo. I want to keep the UI complexity low and really focus on the RPC stuff, of course. Could also use tips on which order to implement things since this is a bit of a *daunting* spec to implement. I'm currently having fun with the unpacking algorithm. :) On Saturday, October 1, 2016 at 7:56:02 PM UTC-4, Nathan Hourt wrote: > > As far as the appetite front goes, I've rather wanted a pure javascript > implementation of capnp on several occasions now, so I'd be quite happy to > see this happen. > > I think websockets support is a must, but ideally the library would be > sufficiently portable that I would be able to use the library, unmodified, > on any particular transport layer I want, with nothing more than a little > glue code between interfaces. The library could then provide some built-in > adaptors for common transport layers (like Node sockets, websockets, etc) > which would allow those transports to be used with no customization, and > also documents how to write adaptors so it's easy to see how to use other > transports instead (exactly like what we see with the C++ implementation > with AsyncIoStream: I can use any transport I want simply by implementing > the interface). > > On Friday, September 30, 2016 at 7:08:01 PM UTC-5, Julián Díaz wrote: >> >> For better or worse my curiosity has led me to try reviving the >> JavaScript implementation of Cap'n Proto; at least all the way to level 1 >> RPC in native JavaScript. >> >> Looking at the current two implementations they don't really feel viable >> to hack on - one is using AMD for the browser (we've moved on!) and the >> other is clearly a mess as-is. >> >> After scratching the surface a good bit, my initial goals for the library >> are: >> >> - Full level-1 RPC support >> - Extensive unit test coverage >> - Full browser and nodejs compatibility >> - Pure ES5 implementation (for speed) >> - Low-to-zero library dependencies (lodash might become a must-have) >> - Loading schema files directly >> >> Stretch goals: >> >> - WebSocket transport support >> - Precompiled schema files >> - Web worker support >> - Level 2+ using WebRTC (can it be done!?) >> - First-class support for bluebird promises >> >> Would love some feedback from this list to hear if there's appetite for >> this, and any features that would make this super useful. I will initially >> aim to provide a similar API as the reference C++ implementation but I may >> take extreme measures to cater more to the target language and typical >> audience. I personally tend to prefer stateless, immutable APIs and will >> try to support that here as well. >> >> - Julián >> >> -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/capnproto.
