I moved to https://medium.com/@steida.
I just released Google Closure DI container. The next big thing for Este. Read: https://groups.google.com/forum/#!topic/closure-library-discuss/A4U4I1W8bhI
I consider dev stack and library to be ready for release. TodoMVC example is stable and will be released once domain estejs.com will be migrated from previous owner which should not take more than week.
There are several options and none of them works except… wait :)
The best documentation tool used for Google Closure api reference is unfortunately not open sourced and probably never will. I googled a lot and we have these options:
JvJsDoc looks nice, except it’s dead project and does not work properly. Plovr has hidden option to generate docs, but it’s incomplete and not documented, probably dead too.
JSDoc 3 uses standard JSDoc format, but to the latest version (3.2.0) understand Google Closure annotation! Not entirely still very well. Btw it uses github.com/hegemonic/catharsis project.
It does not understand goog.scope but that’s not a big deal since Este does not use it a lot anyway.
There are many ways how to update DOM. Manual DOM operations like appendChild etc. It’s fastest and sucks the most too. A lot of boring boilerplate code. OF course we can use various HTML based template engines, and do only partial updates like Backbone does.
Or we can use even smarter Ember or Angular templates. Or Polymer MDV, once it will be ready for production.
HTML template containing a lot of logic in some strange syntax is yet another useless abstraction layer. We are programers, and we want to code in our first-class language.
Este used este.dom.merge. It was fine for 80/20 use cases, but far from ideal. I had a lot of plans with that, but it’s past. Facebook React is exactly what este.dom.merge was supposed to be.
So I incorporated React into Este. Check este.jit.su demos.
As a result, we got a beautiful and concise functional compile time safe syntax for our templates.
So you started with Este but still desperately missing jQuery, or maybe your app just needs some third-party library, for example chartjs.org.
I assume you’ve read developers.google.com/closure/compiler/docs/api-tutorial3.
You know export/extern stuff, but you are still thinking about how to incorporate these third-party libraries properly.
- add bower.json dependency
- add script tag for development, and concat minified file with compiled output for production
Why simple solution is not ideal? Dependencies. Imagine your app uses chart component based on chartjs.org code. You want to add Chart.js code only when yourCompany.ui.Chart component is required to leverage Closure Compiler dead code removal. But goog.require does not work with non closure code and alien code will not pass compiler advanced compilation. So what?
Stringify third-party library and lazy evaluate it when needed. Do not forget to add version in documentation.
You know, the global namespace pollution is wrong. But sometimes we have no choice. Element classes and attributes is such case. That’s why Este uses ‘e-’ as este namespace prefix. Examples:
It looks like candidate for enumeration, no? No. Strings are fine until they are full-qualified. este.Router uses ‘e-router-ignore’ attribute for example. Use this pattern to prevent namespaces clashes.
Very nice article from one of two authors of Google Closure. In short, almost all MVC frameworks are bad designed in term of user experience. Btw, when I developed Este MVC, I decided to implement “Pending navigations” from ground. Now, I am working on rest of tips from article. Read it. Remember it. Use it :)
It can be confusing, but it is really simple.
Soy and object with string properties. This is common scenario for este.Model.
Soy and object without string properties.
I don’t like writing blog posts just to make blogging noise. Este has changed a lot in last several months, if you follow https://twitter.com/estejs, you know.
We fixed coffee2closure fixer, added Bower and GruntJS, whole dev stack was refined.
I definitely have plans to make website, tutorials, etc. but, that’s crap is not so important as the code, unit tests, and demos.
So, stay tuned.