I took a long look at your website, and I think it's very interesting. The great advantage of your approach is that a component is able to access other frameworks/libraries, for example JQuery. LM's architecture also allows this type of approach, but, to be honest, it's quite inefficient. There is a lot of overlap between the core functionality in LM's generic library and what many of these external libraries provide. Also, LM's core library is optimized for LM's own internal generic data structures and methods.

In future posts we'll see how using generic data structures along with generic libraries to manipulate them lies at the heart of LM's architecture - it is this which permits the micro-component model to deliver highly complex applications in such an efficient manner, and allow these applications to be combined and re-combined into new applications.

Thanks very much for stopping by, and I'll be paying attention to your site in the future.

D.

Again, you hit on a key issue when you talk about the tension between the generic nature of a component and the ability to customize it for particular use cases. Future posts will address this issue, but for the time being all I can say is the architecture has several ways of 'abstracting away' the differences between specific (customized) instances of the same component, and then reconstituting in the browser the specific component instance from the generic definition (I hope this makes some sense).

I have been working / researching during my free time on something like this where applications can be built from components. My hypothesis was to test whether assembly separated/distinct from coding of an application leads to reduced complexity/increased flexibility since my focus was on reducing my pain and customer pain in executing large enterprise application developments.

But my approach was more generic in that I don’t have any basic components, what I did was abstract the connections of the components as a language of assembly and hence built a generic framework which in theory can assemble any components using a simple generic language of assembly.

I found that my language of assembly consists of 4 simple metadata, namely, specifying a context, adding components into the context, configuring components into the context and linking components into the context which can lead in theory to assembly oriented application development.

I created a proof of concept web site which was fully assembled from standalone components which helped me to prove it can works, but still need to test it on complex data driven applications or even use it as you are doing to accept data from multiple streams.

I am currently in the process of testing in a limited way whether it can used to develop a proof of concept for a large enterprise application for the architecture industry which I am currently developing for a client.

If you have time and can check my proof of concept website http://www.arshu.com on my approach to solving the complexity/flexibility of web application and give me your comments, i will be greatfull.

I knew you had more up your sleeve than object oriented web programming. Even in your example, we still are completely baffled by some of the forces at play on elementary particles. Their interface appears quite complex indeed, and may even show us more about the very fabric of the universe. Pardon the off topic but I read (and added my own conjecture) to some far out cosmology descriptions. Quantized space time got me curios about reality stretching, and the matter of energy
waves/photons traversing the vacuum in comparison to gravity.

Don't suppose you are considering a small competition to generate interest in using your language tools. There are so many fascinating free open source libs out there on my to do list, I suspect many others share my dilemma.

That's not far off, except that the components are not really objects, and the framework isn't really object orientated. All this is will be covered in later posts, but basically the system keeps code and content separate, which is not the case with methods and properties in objects.

You've definitely grasped the key idea though: by factoring at a much lower level, there are many advantages to be had in terms of compatibility, performance and re-combination.

I've done this type of coding with reused libraries in a desktop environment. But for web programming, this architecture of resources is new to me. I have great expectations for your work Dave, and look forward to messing around with the primitives when they're ready to showcase.

I suspect you're perhaps thinking of components as being similar to an API, in other words: quite large, complex and given to change over time. Within LM, most components are very small, with limited scope for evolution. Once defined and signed-off, a given component remains fixed - it cannot change (apart perhaps from bug fixes). This means that if you build an application based on a given set of components, they will never change. There is no need for backward compatability, as they will remain in the system for ever.

If a given component is modified, then it will have a new ID (more on this in later posts). Applications which can make use of the new component can do so by replacing the old component ID with the new one, whereas developers who prefer the original component are not obliged to upgrade. This is similar to having multiple versions of the same module in a standard architecture, but is less onerous because, being so much smaller and less complex, the issues involved with using legacy components are less drastic.

Since the architecture is based on open source, should a component evolve in a direction which is not useful to a developer, then the developer is free to fork that component. If the component were large and complex, this would be a major undertaking - but, as mentioned, this is not the case. LM components are so small, that forking them will be very straighforward.

As (hopefully) will be clear in later posts, just making the components smaller does not completely insure against the issues you raised. The entire internal architecture of LM is designed to be generic, which means that it should never have to change. You can think of it as a completely general core surrounded by specific components which can access it. I appreciate some of these ideas may seem a bit fanciful, so perhaps it's worth pointing out that we do have a working prototype! Making the core as generic as possible is the single greatest challenge we face at the moment.

Thanks for giving me the opportunity to talk about these (important) issues, and I hope things will get clearer with the future posts.

D.