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 quite, but maybe close enough: https://typescene.dev/docs/guides/first

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?

Agreed, might have rushed this part of the intro. Edited the story to add some more important goals. Thanks for your feedback!

Thanks for sharing your views. The way templates are implemented is definitely a matter of personal preference, I personally don't like mixing two different languages, always seemed like kind of a hack to me. With this restriction Typescene is more like Flutter and SwiftUI, these ended up being very similar. Can't really compare to React and Vue or even Angular, but I can see that some people do prefer looking at XML and that's fine :)

Sure this is a major restriction but there are lots of systems out there with architectures that never changed. I think accepting major changes from framework authors is something we learnt over time, from projects with lots of people who have lots of ideas and the project ends up swinging in all directions.

huh? It's hosted on GitHub pages, not sure why this would happen?

I've spent 5 years working on a JavaScript framework. Finally sharing it with the world! Different philosophy altogether from React and Vue, those are awesome too but Typescene is built with a different purpose — please read the website for a thorough intro.