It's definitely an interesting idea... I could see something like this becoming supported in the browser, and may make sense as an extension to the web components api. It could also be useful as a webpack extension.
Definitely a cleaner approach to rendering than many template libraries. Would appreciate some cleaner examples, and perhaps a flushed out todo-mvc implementation to see a bit more of it.
I don't know that it would replace React + Redux as my preference (though I've now used preact on a few things), but it's nice to see creative options that aren't just re-hashes of what everyone else is doing with just a minor tweak.
A lot of it, yes... but I think the interface is a bit cleaner, and extjs is cumbersome to work with imho. I don't have any use for this, and haven't for a long while, so can't comment. I have written a lot of extjs code in the past, and would rather not look back at it.
I'm happy to see that the JS for the spreadsheet demo (including jquery) is under 1mb... though I still consider 750k to be huge for a JS, for the functionality it isn't bad... Didn't look at the other demos, or interact, was just curious as to the size.
This is not something you would probably want for most public facing sites/applications, one of the larger demos weighed in at 1.7mb of js... again, very impressive for the functionality. I only hope that I can remember about these guys should I ever need this type of functionality again.
Looks like a nice library, but the name doesn't make sense... l10n is short for localization, and i18n is short for internationalization, in that the number replaces that much of the word... x18n, while cute, makes no real sense as a name imho.
It's definitely a better library than many I've seen for the task... that said, a server-side story would be helpful...
x18n(Accept-Language header, default) would make sense, delivering a template instance for that language.
Correction, when ASP.Net came out with its' server-side lifecycle I was enthusiastic, but quickly learned how much of an issue that was in integrating JS responsiveness client-side.
I'm not sure that I agree with the article... the view logic DSL that is JSX isn't bad at all, it couples your render structure with your components. Beyond this, you can have simpler dumb, static-rendering components with react.
What really strikes the chord with me is the Redux pattern for control flow... your state is driven by action creators and dispatchers. With a single state tree, broken up as appropriate, it works very well, even for moderately complex applications.
As far as react's size, I've got a stand alone control (may as well be an application) with a payload (min + gz) of 16.2kb [1] for a date picker control. It's using preact, preact-compat, redux and a few other pieces. So it can be lighter still, still using JSX.
Another lesson learned is to structure by feature, not file type... by coupling your render layer with your components, as opposed to separate templates, you don't have a complicated DSL to learn the behaviors of, but a simple prop="string" vs prop={JsLogic()} ... same for inline js {{js}} vs whatever weird dsl is used for iteration, conditions, etc... in React and its' ilk, it's all JS. Even JSX is a DSL that translates directly to JS.
I don't know enough about Catberry to comment, but having worked in web applications for two decades with I lose count of how many rendering systems, frameworks, toolkits, and techniques over the years... React (or preact) and Redux is the first time I've experienced a set of tools that feels like the "right way" to do it... now, Webpoack, Babel, and the configuration mess is a different story, but once that's setup, it's pretty smooth sailing.
[1] http://tracker1.github.io/md-datepicker/ (note demo isn't gzipped payload)
Better demonstration than most on this topic... It's important to understand how to compose higher level components from lower-level ones.. in the case of the simple redirect component wrappers, they could very well be static functions with the dispatch action inside the render function...
// require-auth.js
export default (redirectTo, component) => (props, context) => {
const {user} = context.store.getState();
if (user) return component;
setTimeout(() => context.store.dispatch(push(redirectTo)), 0);
return null;
}
Having a defered dispatch method would make it a bit easier, in any case, it can be simpler still...
Just the same, very nice article.
It's almost funny, but I've been heading in this direction for a few years, and it works out a lot better.. having related things together, instead of isolation by type just makes it easier to come (back) into a project you may not intimately remember, or otherwise be familiar with.
I'm not sure that I agree with the article... the view logic DSL that is JSX isn't bad at all, it couples your render structure with your components. Beyond this, you can have simpler dumb, static-rendering components with react. What really strikes the chord with me is the Redux pattern for control flow... your state is driven by action creators and dispatchers. With a single state tree, broken up as appropriate, it works very well, even for moderately complex applications. As far as react's size, I've got a stand alone control (may as well be an application) with a payload (min + gz) of 16.2kb [1] for a date picker control. It's using preact, preact-compat, redux and a few other pieces. So it can be lighter still, still using JSX. Another lesson learned is to structure by feature, not file type... by coupling your render layer with your components, as opposed to separate templates, you don't have a complicated DSL to learn the behaviors of, but a simple prop="string" vs prop={JsLogic()} ... same for inline js {{js}} vs whatever weird dsl is used for iteration, conditions, etc... in React and its' ilk, it's all JS. Even JSX is a DSL that translates directly to JS. I don't know enough about Catberry to comment, but having worked in web applications for two decades with I lose count of how many rendering systems, frameworks, toolkits, and techniques over the years... React (or preact) and Redux is the first time I've experienced a set of tools that feels like the "right way" to do it... now, Webpoack, Babel, and the configuration mess is a different story, but once that's setup, it's pretty smooth sailing. [1] http://tracker1.github.io/md-datepicker/ (note demo isn't gzipped payload)Better demonstration than most on this topic... It's important to understand how to compose higher level components from lower-level ones.. in the case of the simple redirect component wrappers, they could very well be static functions with the dispatch action inside the render function... // require-auth.js export default (redirectTo, component) => (props, context) => { const {user} = context.store.getState(); if (user) return component; setTimeout(() => context.store.dispatch(push(redirectTo)), 0); return null; } Having a defered dispatch method would make it a bit easier, in any case, it can be simpler still... Just the same, very nice article.