4 ms·

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 abo

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?

proc0 3y ago
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: { ... } }, }

proc0 3y ago

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: { ... } }, }