jcormont

Hey everyone, in this article I explain how Typescene works using a simple, practical example. I also go through some of the differences with other frameworks.

Bingo

Just read it like natural language. Where it says UIButton.with({ label: "OK" }), that's a Button With a Label of OK. Editors with TypeScript-aware autocomplete (e.g. VS Code) will suggest most of the identifiers here, and tell you what the arguments are for so in practice this works better than you might think.

JSX is a de-facto standard, and it might be convenient in the way that PHP is convenient, but that doesn't mean it's not inherently a hack :) ...

I guess a good rule of thumb would be if you don't see the benefit of using a framework for your project, you probably don't need a framework in the first place :)

Yup no worries, I work with my own standard contract and work like this is excluded. Valid point though, thanks.

Not the content itself. There's no need, it's generated by GitHub pages and works fine (and no issues with SEO).

The search popup is implemented using Typescene though.

I've mostly made this for use with my actual (paid) project work, so the idea was I 'might as well share'. Turned out to be much more work than I anticipated :) Definitely not a hobby project though, I'm hoping eventually a big enough community might pick this up.

Yes, for the View part. There are also other components that handle logic and your data model.

Writing 'new Button' for every single UI component would be really cumbersome, that's why there's also a 'template' syntax which uses static methods (Button.with(...) which creates a button factory).

The onClick event handler refers to a method on an object that exists when the component is rendered, not when the template is parsed by the JS interpreter. So, to refer to the method itself you'd need to do something crazy like go through .prototype or something.

Anyway, yes Typescene does let you supply an actual function in place of the string here, but for me that ruins the 'neat' flow of the view and starts mixing views with logic.

Totally understand how this could rub someone the wrong way, but my intention here is mostly to clarify my own thought process. Not so much "everyone else's shit stinks but mine smells like roses", but rather "my own shit used to stink, so here are my goals for developing something that might work better".

Not saying that HTML isn't also readable (although... once the number of attributes grows larger I always end up with a bit of a mess, but that might just be me).

The real feat here is getting rid of the hacky way that XML and/or template strings and JS are mixed together in the compiler, without sacrificing readability per se.

I do mostly non public work, LoB apps in particular.

Examples?