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:
- Service Providers
- Bundles
- Platforms
- Apps
The slight opinionation of Protoculture comes from:
- Being authored in TypeScript
- Asynchronous-first via
await& the standard Promise APIs - The powerful inversify dependency injection system
- A bundled Redux service provider for a popular and well documented set of conventions for data handling
- Planned integrations with hosting and process management infrastructure like ApplicationInsights
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 Platform, App
and ServiceProvider types.
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 ServiceProviders,
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 main. A 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.
- Laravel
- ASP.NET Core
- Other cool things in the ES community
- Maybe some Scala?
I get it, we all know about JavaScript framework fatigue.
Cynicism over JavaScript is a super hip joke; but this kind of negativity can get the better of us. Protoculture enters the slightly empty space of application frameworks. It is not a middleware platform and is intended to be universal. Simply put, the evolution of the JavaScript ecosystem has been because of all the yet anothers.
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:
- It is a superset of JavaScript. It doesn't bridge and as such requires no special treatment.
- Tight integration with the NPM ecosystem.
- Proactive repository of typing information for extant JavaScript libraries on NPM.
- Future ES features today, no waiting.
- Multi-paradigm type system.
- The language designer behind TypeScript Anders Hejlsberg is responsible for some of the most pervasive programming languages over several decades and has likely influenced many more.
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.