Protoculture is a slightly opinionated ECMAScript applications framework. It sits between your chosen libraries and process managers acting as a layer to organize your abstractions. Everything protoculture does aims to help structure your TypeScript/ES codebase, reducing cognitive overhead and making it easier for multiple people to work together.
The best way to understand how Protoculture works is to think about its main pillars:
The slight opinionation of Protoculture comes from:
await& the standard Promise APIs
The layering Protoculture provides has similar if not identical siblings in other languages and runtimes, its big advantage is in how everything is tied together. In that sense, protoculture is not a full framework, but an application framework.
While Protoculture is authored in TypeScript, you can definitely use it from regular ES as well.
Service providers are responsible for telling the dependency injection system about new configuration and functionality. All
ServiceProvider instances are created when a
Bundle is booted. They are then asked to make registrations against the context.
If you've used Laravel, these should be very familiar.
Bundles represent the topmost entrypoint for a grouping of Apps. Your entrypoint scripts should be able to instantiate
a bundle and call the
run method on it with little fuss. You configure your bundle by way of the
The final role of the
Bundle is to act as a language-level root for an entire dependency graph. This is most
useful when authoring browser applications.
Because bundles are the first thing run in a protoculture application, the bundle module automatically includes
popular fetch, promise and reflect-metadata polyfills. So long as you compose your application using
protoculture will do its best to bootstrap a consistent environment!
Platforms represent the means by which you wish to interact with the environment that Protoculture will make available. Platforms are free to do any kind of bootstrap you need and should be used to help make your app universal.
Apps are probably the easiest level of encapsulation to think about. If you were making a console application, you
would treat the entrypoint in the
App class as your
Bundle can also be made up of multiple applications.
This is especially true when working in the browser as you may have multiple bundles that get minified that wish to reuse apps!
Remember, Protoculture is asynchronous! That means your apps can be too. If a Protoculture bundle detects that it
contains any asynchronous apps, it will automatically set up a heartbeat. This is extremely useful for when you have
long running processes or are using a library that opens up sockets. When all applications are done executing, Protoculture will ask every app to finish up. You don't have to manage a thing!
Protoculture is created by Alexander Trauzzi and is available under the Apache 2.0 license.
Everything inside of protoculture has been distilled out of real production needs. I invite you to try it out and report any ideas or issues in a ticket.
With all the attention pure functional languages like Elm, Clojure, Haskell, Dart, Scala and Go are getting, this is a good question to ask.
My rationale for preferring TypeScript usually goes like this:
If you take all these reasons - and I probably missed some - TypeScript positions itself in every sweet-spot while still being able to chart its own course, making very few if any compromises along the way.
If you look at the history of this package for versions
1.0.15 and before, it probably will look quite different.
The original idea for protoculture was that it would bundle conventions for TypeScript, React, Redux applications.
The spirit of the library remains the same, however I've changed things quite a fair bit after learning even more about the ES ecosystem. Particularly as it pertains to the various platforms it finds itself on.
The only answer you're probably looking for this far down is: Macross.