For Javascript, I actually don't think runtime schema loading should be a goal. These days Javascript is essentially a compiled language anyway, with all the transpiling and minifying. And to load schemas at runtime in a browser, you'd presumably need to rewrite the parser in pure-Javascript. I'd like to avoid having multiple schema parser implementations as they'd be likely to have subtle incompatibilities that would be a pain for developers.
So, yes, capnp -> TypeScript compile-time codegen sounds like a pretty good plan. Then we can get auto-complete in our IDEs and all that cool stuff. :) -Kenton On Sun, Oct 2, 2016 at 10:31 AM, <[email protected]> wrote: > 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 [email protected]. > Visit this group at https://groups.google.com/group/capnproto. > -- 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 [email protected]. Visit this group at https://groups.google.com/group/capnproto.
