Advice, opinions - Google Closure and Dart

[julien]

Hi,

First of all this thread is not meant to be another closure library
vs. x or y troll, I'd just like to have your opinion :)

I got started with closure library and templates and find that is has
quite a steep learning curve: the library is huge, and not often very
well documented, however grabbing the source and poking around helps
understanding the internals.

Also, having experience with strong typed languages (Java,
ActionScript3) helps me understand the concepts and I find closure's
concepts very useful in the JavaScript development workflow,

However, I still am not using closure in big projects, mostly because
I don't feel ready yet ... that said, in the current project I am
working on, I can start feeling the lack of 'closure' in our app.

I also recently started having a look at Dart, and I find it also
fills the gap when it comes to type checking and bringing oop concepts
to JS

I was wondering if it was worth starting to use closure in my big
project or if I just switch to Dart once it's stable enough...? What
would you do, and what does the closure team think about Dart?

Also, if you have good resources concerning MVC with closure, or
examples/tutorials of single page apps, I'd be delighted (I have had a
look at the Releif framework, but I'd like to understand the internals
before starting using it, I also started checking goog.history and
goog.events packages so I'm starting to get an idea of how this works)

Thanks

[Jay Young]

I'm not a Googler, but welcome to the community.  I hope you find everything you're looking for.  :)

On Sunday, January 22, 2012 7:53:46 AM UTC-5, Julien wrote:

Hi,

First of all this thread is not meant to be another closure library
vs. x or y troll, I'd just like to have your opinion :)

I got started with closure library and templates and find that is has
quite a steep learning curve: the library is huge, and not often very
well documented, however grabbing the source and poking around helps
understanding the internals.

No question.  This is probably the biggest barrier to entry.  If you haven't yet, look into Plovr (http://code.google.com/p/plovr and http://plovr.org).  It's a tool that encapsulates the Closure Compiler, Templates, and Library and automates build tasks so that you don't have to care.  It lowers the barrier substantially.  It's still required that you learn how the Compiler and Templates work in order to maximize effectiveness, but it removes the tedium.

No doubt that documentation is lacking.  Not so much the API docs (those are pretty good, in my opinion:  http://closure-library.googlecode.com/svn/docs/index.html), but the world of blogs and videos that delve into deeper details is sadly non-existent.

 

Also, having experience with strong typed languages (Java,
ActionScript3) helps me understand the concepts and I find closure's
concepts very useful in the JavaScript development workflow,

I LOVE the type system that Closure uses.  I know there are aspects of it that the Compiler can't verify, but even just having the ability to document things like function, union, and record types at API boundaries is huge.  I'm pretty sure that even if I'm working on a non-Closure project, I'll keep using this type system whenever I'm allowed.

However, I still am not using closure in big projects, mostly because
I don't feel ready yet ... that said, in the current project I am
working on, I can start feeling the lack of 'closure' in our app.

The best way to learn is to dive in.  I started using Closure in a casual side-project.  I re-wrote various parts of the thing  a couple times as I learned how to better use Closure, and I'm a better developer for having done it.

I also recently started having a look at Dart, and I find it also
fills the gap when it comes to type checking and bringing oop concepts
to JS

When using Dart, I really miss union and record types.  Other than that, I think they nailed it.  Again, being able to document API boundaries while not having to declare a type for every local variable is awesome.  It's what I've been doing in Closure for years.

 

I was wondering if it was worth starting to use closure in my big
project or if I just switch to Dart once it's stable enough...? What
would you do, and what does the closure team think about Dart?

Dart isn't going to be stable for some time, and it won't be mainstream for even longer, if ever.  Closure is in use in production all over Google's properties, and even outside it.  Long-term support has been pledged by Google (non-binding, "can't make any promises but..."-winkwink, kinda thing) and even outside devs have said if Google abandons it, they'll fork it and maintain it because it's used internally (I think this was Bjorn from Rackspace).

 

Also, if you have good resources concerning MVC with closure, or
examples/tutorials of single page apps, I'd be delighted (I have had a
look at the Releif framework, but I'd like to understand the internals
before starting using it, I also started checking goog.history and
goog.events packages so I'm starting to get an idea of how this works)

As for good resources, the only one I can really think of is "Closure: The Definitive Guide" by Michael Bolin.  Don't be afraid to search the mailing list either (the new Groups interface makes this really easy).  Finally, be comfortable reading code.  The Closure style of writing Javascript isn't welcome everywhere (there were a lot of experts who gave it a cursory glance when it was open-sourced and scoffed), but there are still gems in there that you can learn from.

I'm the developer behind Relief, and I'm always happy to help people learn and use it (and help with bug reports or feature requests).  If you want to ask questions, try the mailing list: https://groups.google.com/forum/#!forum/relief-framework.  I'm usually quick to answer questions and resolve issues.  Don't let the project history fool you.  I'm still working on it, and I have big plans going forward.  Community input is always hugely welcome.

I wouldn't call it an MVC framework per se, though it might evolve along those lines.  My purpose in writing it was to remove the cruft around application structure (navigation management, RPC boilerplate, etc) so you can write interesting stuff earlier.  I can definitely see growing a full MVC/MVP layer on top of what's there.

[Johannes Nel]

Don't hesitate to start using closure. Everyday you code without advanced mode compilation is another day of pain in debugging. Get Bolin's book, get a proper build tool, but just start using all of it. go advanced mode compilation from day 1. Even if it means you have to rewrite and annotate tons code, you will save time in the long run. 

Using closure was the best decision we ever made in the javascript world.

--
j:pn
\\no comment

[Nick Santos]

I think it's fair to say that Dart is heavily influenced by Closure
and GWT and V8 (many of the same people work on it). It has many great
ideas that Closure probably would have adopted if we didn't have to
worry about compatibility issues with browsers or with existing use
cases.

That said, we're not naive. There are many well-designed languages
that are not successful, and many poorly-designed languages that are
widely used. So I think that Closure team doesn't want to jinx Dart by
passing judgment on it one way or the other.

If you're looking for a way to "practice" Closure (or Dart), I think
the best way is to use it to write tests. That's how Closure got wide
adoption within Google. The Closure test runner was much better than
everything else at the time. And if you find out that you don't like
one framework, it's a lot easier to rewrite tests in a different
framework than it is to rewrite the core of your app.

Nick

[Johannes Nel]

this is a fair comment, I have not however seen a similar eco system for dart that closure has. the templates and the livecycle of the library is a huge part of why we use closure. I am sure Dart will still evolve these things (or it might already be doing) but this is massive gain for any existing or new project.

[Bjorn Tipling]

> I LOVE the type system that Closure uses.  I know there are aspects of it
> that the Compiler can't verify, but even just having the ability to
> document things like function, union, and record types at API boundaries is
> huge.  I'm pretty sure that even if I'm working on a non-Closure project,
> I'll keep using this type system whenever I'm allowed.

I don't love the type system. I immensely prefer static typing over
truthiness and other silliness in dynamically typed languages, but the
Closure Compiler warnings lead to 99% jsdoc comment fixes. It hardly
ever finds anything that would actually break in runtime, fixing
warning feels like unnecessary busy work. We have quite a bit of type
casting jsdoc comments in our code that is like this.doSomething_ (/**
@type {Object} */ someVar);. These warnings are probably correct given
the explicit notation, but pedantically so, and if I removed the
litany of extra jsdoc notation inside the code our app would not
break. A linter that requires === for equality evaluation is much
simpler, requires less work and actually finds problems.

In addition, while we work hard to have zero warnings for our own code
from the compiler, and in fact our build fails if Closure Compiler
reports any of our own making, we have still have warnings from the
Closure Library itself. So not even the authors of the Closure Library
take it seriously. Otherwise we could use the Compiler's error out on
warning instead of some hack that monkey patches the Closure Library
build tools so we can check the stdout and stderr output against
expected warnings.

[Nick Santos]

This comment is slightly misleading in context.

Just to clarify, the warnings that Bjorn is referring to are not type
warnings. They're almost all private/protected warnings (i.e.,
@private). While almost all users care about type warnings, very few
users have historically cared about the access control warnings, and
most teams just turn them off (which the compiler api lets you do
easily).

Nick

[Bjorn Tipling]

Having said this, the benefits apparent benefits of a type checking
system is more than just an equality operation. Often runtime errors
involve attempting to call methods on a null object or calling a
method on an object that doesn't have it. Closure Compiler type
checking attempts to prevent this, yet I still run into these problems
even though we have the compile warnings. I never really consider when
debugging such a problem that maybe better use of the jsdoc notation
might have prevented it. I will try to remember that. The type checker
doesn't check to see if an object has the methods that are assumed it
has.

[Bjorn Tipling]

> Just to clarify, the warnings that Bjorn is referring to are not type
> warnings. They're almost all private/protected warnings (i.e.,
> @private). While almost all users care about type warnings, very few
> users have historically cared about the access control warnings, and
> most teams just turn them off (which the compiler api lets you do
> easily).

I do not understand this. First of all we are seeing lots of type
warnings in things like XhrManager, goog.events.events and
goog.net.XhrLite, the goog.ds.* where some of the problems are the use
of nonexistent type annotations. But why would you be ok with problems
with access control warnings? I anticipated a comment such as "old
code, have not yet fixed" not "actually we are ok with this because
most people do not care."

We care a lot about access control on private properties, which is why
we spend the time and write getters and use the getters and setters
available to us.

[Bjorn Tipling]

I shouldn't have used quotes to reinterpret a statement, it makes it
look like a literal quote. Sorry. My point still stands however. I
don't think the Closure Library should ship with warnings.

[Nick Santos]

have you seen this FAQ item? is this the issue you're having?
http://code.google.com/p/closure-library/wiki/FrequentlyAskedQuestions#When_I_compile_with_type-checking_on,_I_get_warnings_about_unkno

[Bjorn Tipling]

That is the issue. Heh. Thanks.

On Jan 25, 12:05 pm, Nick Santos <nicksan...@google.com> wrote:
> have you seen this FAQ item? is this the issue you're having?http://code.google.com/p/closure-library/wiki/FrequentlyAskedQuestion...

[Nick Santos]

heh. I thought it was a good demonstration of the trade-offs between
Dash, where the ideas are baked into the language, and Closure, where
they're grafted on post-hoc.
- It's easier to use Closure with existing code
- It's easier for type resolution to break down in cryptic ways
- It's easier for the community to reject new features, or accept them
incrementally (like @private checks)

[John Lenz]

In practice, these 3 checks are the most effective, catching the most common typos:

- the var existence checks

- the missing property checks

- the function/method arity checks

These alone make using the compiler in my book worthwhile, everything else is just gravy.   I can't say that "==" vs. "===" has been any kind problem that I regularly encounter as needing "===" usually means you are being fuzzy about the types you expect.

[John Lenz]

On Wed, Jan 25, 2012 at 1:23 PM, Nick Santos <nicks...@google.com> wrote:

heh. I thought it was a good demonstration of the trade-offs between
Dash, where the ideas are baked into the language, and Closure, where

Dart, I think you mean. 

[Nick Santos]

On Wed, Jan 25, 2012 at 5:27 PM, John Lenz <conca...@gmail.com> wrote:
>
>
> On Wed, Jan 25, 2012 at 1:23 PM, Nick Santos <nicks...@google.com> wrote:
>>
>> heh. I thought it was a good demonstration of the trade-offs between
>> Dash, where the ideas are baked into the language, and Closure, where
>
> Dart, I think you mean.

according to freedictionary, they are synonyms
http://freedictionary.org/?Query=dart
i also sometimes call it "Scoot" or "Flash".

[Johannes Nel]

An IMO.

I cannot really envision an annotated based static check that gives the flexibility and the power without compromise in a langage as flexible as JS. 

Yes there are things which we all think 'could' be better, but the trade offs are concrete at this point, so no easy decisions given the constraints of an existing code base and a lot is external users.

I don't love the type system. I immensely prefer static typing over
truthiness and other silliness in dynamically typed languages, but the
Closure Compiler warnings lead to 99% jsdoc comment fixes. It hardly
ever finds anything that would actually break in runtime, fixing
warning feels like unnecessary busy work. We have quite a bit of type
casting jsdoc comments in our code that is like this.doSomething_ (/**
@type {Object} */ someVar);. These warnings are probably correct given
the explicit notation, but pedantically so, and if I removed the
litany of extra jsdoc notation inside the code our app would not
break. A linter that requires === for equality evaluation is much
simpler, requires less work and actually finds problems.

In addition, while we work hard to have zero warnings for our own code
from the compiler, and in fact our build fails if Closure Compiler
reports any of our own making, we have still have warnings from the
Closure Library itself. So not even the authors of the Closure Library
take it seriously. Otherwise we could use the Compiler's error out on
warning instead of some hack that  monkey patches the Closure Library
build tools so we can check the stdout and stderr output against
expected warnings.

[Bjorn Tipling]

I'm glad I made an erroneous comment yesterday, because if I hadn't I
wouldn't be at 0 warnings now. I think there is value in jsdoc
notation, it's better than not doing anything, but in a perfect world
I would be writing go-lang in the browser. :(

[GordonHo]

Thanks as well, i always was wondering about those warnings as well, though I didn't look into them yet.

Saved me some time here :)

I did two projects by now using closure and i can only agree - i wouldn't want to write JavaScript applications without it.

However was missing some introduction into the components, controls and co.

I've read the closure guide book, however i had the feeling that there are quite some discrepancies between the offical closure demo's and the explanations in the book.

In addition there are really almost no sources available to teach about the basic design principles you should follow when using closure.

Quite sad, as i believe that's one of the biggest barries. As said before the api documentation is quite good, and diving into the code works quite well when looking for an answer.

Cheers

[Michael Bolin]

I think you really have to ask yourself: would you really have so few type-related errors if the compiler/library hadn't forced you to specify them so precisely? Perhaps the reason why you don't feel the compiler is catching many is because it has helped you write better code that is less susceptible to such errors the first time around :)

[Johannes Nel]

what kind of type percentages do you guys have? We are pretty diligent about annotating and currently running at 97.4% I would like 99.9*% but what is really achievable.

the compiler has saved our bacon in some pretty subtle as well as explicit ways. 

On Fri, Jan 27, 2012 at 1:44 PM, Michael Bolin <boli...@gmail.com> wrote:

I think you really have to ask yourself: would you really have so few type-related errors if the compiler/library hadn't forced you to specify them so precisely? Perhaps the reason why you don't feel the compiler is catching many is because it has helped you write better code that is less susceptible to such errors the first time around :)