A Declarative Front End Framework from Scratch [pdf]
raw.githubusercontent.com
A Declarative Front End Framework from Scratch [pdf]
1–4 of 4 posts
Re: A Declarative Front End Framework from Scratch [pdf]
#2This is cool. I was trying something along these lines with PureScript. May main motivation was this:
> For instance, a to-do item will only "run" once, and any additional updates will need to happen via calls using its controller, or by it itself listening to events and reacting to them
Additionally, I think another feature of this framework would be using a configuration file as context, which uses some form of template files, and this way unless an abstract feature is needed, you can create entire apps by creating templates and one config file. I think TS might be a better choice than PureScript which I have not checked if it is even maintained anymore.
Re: A Declarative Front End Framework from Scratch [pdf]
#3This is cool. I was trying something along these lines with PureScript. May main motivation was this: > For instance, a to-do item will only "run" once, and any additional updates will need to happen via calls using its controller, or by it itself listening to events and reacting to them Additionally, I think another feature of this framework would be using a configuration file as context, which uses some form of tem…
Thanks for the comment. I never got around to try PureScript, but on my to-do list. Not sure how active it is, but looks like it is alive still. What I like about TypeScript is that you are working so close to the target language, so you know what you will get, which makes it easier to try to minimize app/bundle size. But, TypeScript types can be quite tricky and the type system doesn't seem as "smart" or powerful as Haskell (and I presume PureScript).
Not sure if I fully get your idea about having a configuration file and templates. Would it be a convenient and concise way to create "simple" pages basically? Pages that are "generic", e.g. all just displaying some content? So you would only need to create more complex pages outside the config, e.g. those that are interactive?
Re: A Declarative Front End Framework from Scratch [pdf]
#4This is cool. I was trying something along these lines with PureScript. May main motivation was this: > For instance, a to-do item will only "run" once, and any additional updates will need to happen via calls using its controller, or by it itself listening to events and reacting to them Additionally, I think another feature of this framework would be using a configuration file as context, which uses some form of tem…
Thanks for the comment. I never got around to try PureScript, but on my to-do list. Not sure how active it is, but looks like it is alive still. What I like about TypeScript is that you are working so close to the target language, so you know what you will get, which makes it easier to try to minimize app/bundle size. But, TypeScript types can be quite tricky and the type system doesn't seem as "smart" or powerful as…
Ah, nice, I'll need to get back on it. Basically this config context contains the relationship between (the equivalent of) Views, Models, and Controllers. The components are separate files, and are only referenced in the config along with additional settings. The framework would then do most of the heavy lifting to glue things together, while preserving rendering efficiency (no unnecessary re-renderings)
Part of the motivation is to optimize the developer experience for any given app, with the observation that all UI apps, at least within a specific context like the DOM/HTML/REST, can be fully abstracted away. Development would then become mostly about specifying the unique information for that stack and context, i.e. server endpoint url, response data structure, html structure, and event processing hooks. In other words, it's supplying only the minimum required amount of information to build arbitrarily complex applications. "Minimal" here is not necessarily simple, it could still be something complex, it would just be unique to that app.
I didn't get much working with PureScript, as I was still exploring some existing frameworks that might already achieve this, but as a quick example, it would be something like:
import models // contains pure functions for data mapping / normalization
import views // contains templates and styles
import controllers // contains event mappings
export {
view: view1,
"component_name": {
model: model1,
views: [ view2, view3 ],
controllers: [ controller 1 ]
options: { ... }
},
}