Appium V2 Architecture

[bootstraponline]

discussion link

Goals:

• Avoid Spaghetti code:
  Use monocle-js, or ES7 async/await syntax (both use generators under the hood).
• Exception Handling:
  promises (with async await syntax)
• Clearer structure, greater use of OO patterns. E.g., discussion of lib/devices.
  • Evaluate move to TypeScript
• Evaluate gulp (It uses Javascript feature better.)

Links:

• ES6/ES7 features list in Traceur https://github.com/google/traceur-compiler/wiki/LanguageFeatures
• monocle: https://github.com/jlipps/monocle-js
• async/await/es7 overview: http://www.joezimjs.com/javascript/synchronizing-asynchronous-javascript-es7/
• promise https://www.youtube.com/watch?v=MNxnHbyzhuo (focus is on error handling/composition rather than syntax. Dominic has since joined Google and is working on es7/traceur).
• AtScript presentation

[sebv]

Changed title, this should ultimately be spec.

[0x1mason]

Goals:

• Clearer structure, greater use of OO patterns. E.g., discussion of lib/devices.
  • Evaluate move to TypeScript

[bootstraponline]

• AtScript presentation
• Comments in the TypeScript roadmap blog post are interesting
  • TypeScript doesn't currently support async/await

[sebv]

There will already be lot's of extra syntax sugar in ES6/ES7.

[sebv]

Best if people edit the description with new items, then keep comments for comments.

[jlipps]

re: typescript, from http://stackful-dev.com/typescript-nodejs-vim-and-linux-oh-my.html:

I googled for a bit and found out that imported modules have to have interfaces defined so that they can be imported. There are two ways to define module interfaces:

1. You have a module written in TypeScript that exports some objects. No problem here -- the compiler knows how to handle those.
2. You augment your module with an interface definition file that the TypeScript compiler uses to infer what object the module exports at compile time. One such definition is the node.d.ts file that contains the interfaces for all built-in Node.js objects.

The latter option above seems like a real deal breaker.

also, from @dshaw (https://twitter.com/dshaw/status/527143090809618432):

[Node.js + Typescript is] a pretty esoteric combo. Not that I know of. In fact, I don't know many TypeScript apps outside Redmond.

[sebv]

There is already classes in ES6 http://javascriptplayground.com/blog/2014/07/introduction-to-es6-classes-tutorial/

[jlipps]

in terms of increasing OO cleanliness, looks like ES6 is also getting native support for classes: http://javascriptplayground.com/blog/2014/07/introduction-to-es6-classes-tutorial/

in terms of greater type safety, it's not yet a part of the spec I don't think but there's a strawman up for type annotations: http://wiki.ecmascript.org/doku.php?id=strawman:types&s=types

we can access both of these right now with traceur as well. so far i'm feeling like moving forward with JS's future rather than a "compiles to JS" language. I have a bad feeling about pegging ourselves to a different language. as atscript and dart indicate in addition to typescript, microsoft and google are doing their best to help out the community but it's not clear yet what will catch on and what will be left by the wayside in a year (dart). ES6/ES7 on the other hand are always going to be around because it's part of the core language. i'm therefore more happy to do some transpiling now and eventually remove traceur entirely.

my vote is for getting what we need by moving into the future of JS (and thereby having the ability to speak into that future as well) rather than relying on tools of unknown worth and longevity.

[bootstraponline]

my vote is for getting what we need by moving into the future of JS (and thereby having the ability to speak into that future as well) rather than relying on tools of unknown worth and longevity.

👍

[0x1mason]

@jlipps It sounds to me like you misunderstand AS and TS. Unlike Dart,
they aren't different languages from JS. I don't know much about AS other
than it's very similar to TS, but I do know TS is a working proposal for
ES6/7, not a counter vision. It promises to remain compat as the ES6/7
standards change. So for all intents and purposes, AS/TS are the future of
JS, or a vision of it anyway. TS transpilation back to ES3 can retain
comments, so I don't see much risk in moving to TS. If for some reason we
needed to jump ship, it wouldn't be too difficult.

On Tue, Oct 28, 2014 at 1:14 PM, Jonathan Lipps notifications@github.com
wrote:

in terms of increasing OO cleanliness, looks like ES6 is also getting
native support for classes:
http://javascriptplayground.com/blog/2014/07/introduction-to-es6-classes-tutorial/

in terms of greater type safety, it's not yet a part of the spec I don't
think but there's a strawman up for type annotations:
http://wiki.ecmascript.org/doku.php?id=strawman:types&s=types

we can access both of these right now with traceur as well. so far i'm
feeling like moving forward with JS's future rather than a "compiles to JS"
language. I have a bad feeling about pegging ourselves to a different
language. as atscript and dart indicate in addition to typescript,
microsoft and google are doing their best to help out the community but
it's not clear yet what will catch on and what will be left by the wayside
in a year (dart). ES6/ES7 on the other hand are always going to be around
because it's part of the core language. i'm therefore more happy to do some
transpiling now and eventually remove traceur entirely.

my vote is for getting what we need by moving into the future of JS (and
thereby having the ability to speak into that future as well) rather than
relying on tools of unknown worth and longevity.

—
Reply to this email directly or view it on GitHub
#3911 (comment).

[jlipps]

from @seanhess via twitter on typescript:

Yeah it's great! Only complaint is no generators yet but I shouldn't be using node 0.11 anyway :)

[jlipps]

It sounds to me like you misunderstand AS and TS. Unlike Dart, they aren't different languages from JS.

Yes, I was speaking loosely. They're different languages in that what they provide on top isn't necessarily going to be identical to what ES6/7 do. Or if it is, then there's no benefit in using it in the first place since its goal is the same as traceur. But my understanding was that they were providing new features on top of the existing language---type checking, classes, etc... And that they are adding this in their own way, which may or may not be the same way the JS standards body decides to go.

But in general, I just don't see what the main benefit of Typescript would be over just using ES6/ES7 features via traceur. Given that I don't see the benefit, I don't see anything worth taking even the slightest risk that TypeScript goes by the wayside. Maybe you can help me see the benefit.

[seanhess]

You accidentally mentioned me via my twitter handle, so I'm butting in, but...

Strict types are awesome. I mean, obviously TS and AS don't provide any benefit over Traceur unless you want strict typing. But having put several large javascript applications into production I can tell you it greatly benefits from a little love from the compiler. It's so nice to see what you broke when you change something.

You don't need to worry about Typescript going away. Facebook's Flow and Google's AtScript are adopting the same annotations syntax. Once those projects are more developed, you should be able to pass typescript code more or less straight through the flow or at script compilers. (Or with minimal modifications.)

Anyway, best of luck with your project!

[jlipps]

thanks @seanhess!

[0x1mason]

I think the single biggest benefit is what seanhess mentioned:

It's so nice to see what you broke when you change something.

We already use static analysis, but JSHint isn't that helpful for error checking. TS gives you powerful compile-time checks (sounds like AS provides powerful run-time checks). That alone equals a huge wins for the quality of our project since there are that many more issues that will be resolved before code even hits review.

Good static analysis also allows for much better dev tooling. My IDE, from JetBrains, has support for TS and I think there are plugins available for a number of other code editors. Good tooling means better refactoring support, better dev-time error catching, and shorter dev cycles. Being able to do things like quickly find where a function is defined makes the code much easier to understand and bugs much less likely to occur in the first place.

Since I wasn't familiar with Traceur until your post, the only other features I know TS offers are a different module api (which I have no idea is better or worse) and generics/templates. Generics are freaking awesome and impossible without static transpilation. AS promises run-time reflection and the ability to attach metadata to properties, both of which make it easier to use patterns such as Inversion of Control. We could use IoC in a number of ways, but most obviously for implementing a plugin system.

I don't know much about Traceur, so I'm def open to it. However, I don't believe Traceur affords the level of static analysis as TS. That alone is enough to make me think even if we restricted ourselves to ES6/7 lowest common denominators of TS, AS, and Traceur, using TS tooling still provides big wins for us and, more importantly, our users.

When taken together, I think the benefits of TS outweigh what appear to be fairly minor risks. If the project dies, then migrating to ES3 or Traceur or what have you shouldn't be too difficult (but deserves further study).

Anyway, I'll be excited to implement any of the 3, as I think stronger typing will be a big help.

[0x1mason]

I'd also like to add terminal assertions by 2.0.

[jlipps]

I'd also like to add terminal assertions by 2.0.

these should be much, much easier with async/await

[sebv]

The TS reasoning makes sense when you are building a big FE application in a browser. However If I were to carry on this reasoning on the server side, where we are not tied to Javascript, I'll probably conclude that we should use another programming language.

[bootstraponline]

wasn't appium written in python at one point?

[sebv]

Yes, but even python don't cut those criteria.

[bootstraponline]

what language would?

[sebv]

C++/Java would, I am not even sure Go would, most go programmer use vim like editors. When you use dynamic languages, it's becomes hard to write good editor for it.

We have chosen to write code in JS, either embrace it or dump it. Bottom line, it is a dynamic language based on event loop (i.e. not oroutines, even if they are becoming part of the picture). Don't try to make it what it is not.

[0x1mason]

We've already made JS what it is not by writing a large application with it. However, I don't think dumping JS is practical at this point, especially if there are tools available that mitigate some of its weaknesses.

TS doesn't mean giving up JS's dynamic capabilities--all JS is valid TS--it means better static analysis. There's nothing anti-JS about that. We already do static analysis, it's just not very useful for error catching. TS gives us the ability to enforce static types when we think it's beneficial.

[bootstraponline]

The goal of TS/AtScript is to become JavaScript via some eventual future ECMAScript standard, it's not a new language. The question isn't JS vs some other language, it's about how far in the future do we want to go in selecting the version of JS to use. Traceur seems like a safe bet however it doesn't address static typing.

[sebv]

Ok let's go to the extreme and compile Doom to run on the browser, and then you want to use tools like mocha to test it. Do you think it is going to work well?

You see, ultimately it's not about what is the language is compiled to, it's all about the stage where humans write it. What you gain in design/tooling, you'll loose it in testing/flexibility. This is an old arguments and to write server code, dynamic language have an history of being better.

To write front end app the balance tends to be in favor of Strongly typed language, but even in this space the tendency is reversing with languages like Rust.

I would agree that JS is not the easiest language to work with on server side, but in spirit, using transpilers like TS and to a less measure CoffeeScript is using a different language. The subset of generated Javascript is smaller than what you can write in pure JS.

[bootstraponline]

Ok. If we focus only on Traceur then with no TS, any objection?

[0x1mason]

👍

[sebv]

I 'll definitely use most of the syntax sugar, there is no reason for them to be unstable, it's straightforward to implement in traceur.

[0x1mason]

I see the legit use of spread now. Here's what the first examples I saw did:

var wu = function (foo, bar = "baz", ...args) {
  // do stuff
};

wu(someObj, ...["a", "b", "c"]);

That's terrible, tho can be dealt with in code review.

[sebv]

What's terrible? this is for when the array is dynamic, like apply.

[0x1mason]

look at the signature of wu and look and the arguments getting passed in. They don't align. There's a magic token that makes the function invocation behave in ways that aren't straightforward. K.I.S.S. It's not good design.

[sebv]

Yeah, to use the 2 feature together is probably not great, nevertheless both feature are useful.

[0x1mason]

I think we need to add to the style guide that parameters with default values must come last in the function sig:
func (arg1, arg2, arg3 = "ta").

[sebv]

https://github.com/mozilla/addon-sdk/wiki/Coding-style-guide

[0x1mason]

@bootstraponline Do you think we should rename this thread and create a new one for 2.0 features?

[0x1mason]

FWIW, I asked one of our non-core, regular contributors if static typing would discourage him from contributing. I don't think we really need to worry about the regulars--their skill level is quite high and are obviously motivated. It's the one- and two-offs who are really the question. Hopefully Angular gets there first so we can gauge the reaction.

Anyway, we'll hash it out later.

[bootstraponline]

I think once there's IDE support (ex: jetbrains) then static typing will probably be helpful to people.

In terms of the thread, I'm not sure why this one was closed. It'd kind of long so maybe a new one with a summary would help.

[0x1mason]

@bootstraponline I'll live with @jlipps suggested scope if we can agree that sticking a default parameter in the middle of a function signature function (foo, bar = "baz", ...args) is generally a bad idea. We also need to do some more testing before implementation, namely:

1. Looking at the impact of generated code on debugging. The code needs to be easily debugged by command line and graphical debuggers. Sourcemaps should make that easy, but due diligence says we should try it out. For luddites who are still dumping vars to console, we need to make sure either they aren't totally disrupted by post-processed member names that appear in their dumps, etc., or are cool with the transition to a cli/graphical debugger.
2. Make sure that the new patterns are naturally integrated into the existing codebase. By that, I mean someone new to the project shouldn't be confused by an abrupt change in style. That's one of the reasons why I wanted to keep the pre-2.0 scope small. Let's make sure whatever we do isn't discontinuitous.

I'll probably think of some other things later.

[0x1mason]

@bootstraponline

In terms of the thread, I'm not sure why this one was closed.

Late night mis-click. Reopened.

[0x1mason]

if we can agree that function (foo, bar = "baz", ...args) is unacceptable.

Another way of saying this is default parameters should always be last.

[sebv]

Too much details....

[0x1mason]

Too much details....

Not sure what you mean.

[jlipps]

After much more conversation in chat, I think I've convinced @0x1mason that confusion because of misuse of rest/spread is unlikely. My main point is that we should use them as follows:

• rest: function func(...args) { in lieu of var args = Array.prototype.slice.call(arguments, 0);
• spread: func(...args); in lieu of func.apply(bindObj, args);

There really shouldn't be a lot of reason to use them in other cases. It'd be nice if ES6 implemented named args (like Python's **kwargs) but it doesn't. It limits the utility of rest/spread to these kind of cases, but they are quite useful even so.

And I think if someone comes up with a use that is different than one of these, we should discuss it in code review and adjust the style guide as necessary with any resulting decisions.

[bootstraponline]

if someone comes up with a use that is different than one of these, we should discuss it in code review and adjust the style guide as necessary with any resulting decisions.

I think this makes sense. 👍

[jlipps]

\o/ we have finished rewriting appium

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.