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.
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 :)
I'm not shopping frameworks, I just found it peculiar that the marketing is all about what the framework doesn't do. It seems like you think that the word framework in itself describe the purpose.
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.
> I've mostly made this for use with my actual (paid) project work, so the idea was I 'might as well share'.
Have you made sure you got authorisation to release the code, or that you were in a case where you didn't need such authorisation? Because in a lot of cases the code is not the developer's property, it belongs to the company who paid him to develop it.
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.
If it would be 2013 the "hacky" way would be acceptable, but JSX is a de-facto standard that is supported by all tools used in production (incl. TypeScript, Babel, your favorite colorizer, language server extensions, ...).
Imho the proposed way sacrifices readability a lot (what does "with" do? is it like the infamous JS with? what is the first, second, third, ... argument?).
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 :) ...