Often there will be parts (blocks – see further down for an explanation) that you want to add to an existing or new application. These parts are missing items of functionality which make the application complete. Today's issues often revolve around being able to quickly and easily find parts that adequately satisfy the functionality that is missing without adding bloat.
But when some parts are found you often find yourself in the situation where other parts have to be used, and/or some prior configuration (significant amounts) is required before using it. Frameworks are extremely poor when it comes to supplying what you need since there is additional baggage that has to be handled as mentioned above.
How does one grab what they need without requiring anything else? A key answer to this is with platform libraries since they do not require you to use what you don't need. Instead the libraries underlying design (eg through loose coupling) permits software developers to use only what they need, and not what they don't want.
An inspiration of this is the NetBeans Platform because the designers have taken into consideration that every application is different in terms of its requirements, and have designed the platform as such that if anything else is required it has sufficient design reasons for including it (eg makes it easier to implement a given piece of functionality).
Another issue is being able to easily integrate a part into an existing application. Especially if this application is used by the masses. Difficulties arise when significant changes need to be made in order to incorporate the part. In this situation you would go for a different part (from a different supplier - see further down for an explanation) provided there are some choices out there.
Certainly we are starting to see the emergence of platform libraries as a trend away from frameworks. So you could be mistaken for thinking that libraries are back with a vengeance. Indeed that is exactly what is occurring since software developers are after a balance between flexibility and simplicity when building applications.
JFX Blocks is designed to quickly and easily build new JavaFX applications (mobile and desktop, not mobile web), and add functionality to existing JavaFX applications. Currently JFX Blocks is at the design stage therefore any core functionality that is mentioned may change.
Emphasise a declarative approach to building applications with a focus on what is needed
Use mixins as “building blocks” to easily build against other existing code
Minimise or remove the need for configuration before using a “block”
Provide default behaviour for every “block” so it is usable straight “out of the box” in a new or existing application
Emphasise the use of design to provide “blocks” that produce huge benefits with little effort
Maintain high documentation standards that incorporate an extensive use of examples (samples) for getting started
Minimise the use of tight coupling
Maintain high coding standards
Provide core functionality that will work on both mobile (not mobile web) and desktop applications without any major changes (JFX Blocks common profile)
Block – A self contained piece of functionality that is loosely coupled (a mixin)
Container – Contains a set of blocks that handle a specific (unique) area (a JAR)
Blueprint – Like a block except it contains no default behaviour and it only specifies how to structure something (a mixin that is like a interface)
Connector – Enables a block to be “connected” to an application (a class)
Supplier – Designs and creates the blocks/containers/blueprints/connectors
Builder – The user that builds or partly builds an application using what is provided by supplier(s)
A basic (generic) lookup system that can obtain physical files, JAR resources
IO (Input/Output) utilities
Factory for controlled creation of “blocks”
Handle all aspects of the application's lifecycle (eg startup, shutdown, resource loading, setting up user settings)
A basic (generic) persistence system for general data, program and user settings