Roadmap (aka "the first and most important thing to do" or "focus")

[rborn]

Hi everyone,

I'm reading up and down all the issues in this repo and I don't manage to find out what you are actually trying to start with. My next words might be due to the fact that I don't know many of the internal talks of the TiForward group so please don't feel offended and be assured I don't want to hurt anybody's feelings :)

I see there are many talks about ES6 support, layout support, and even a dedicated IDE for Ti? But what I don't get is what are you actually wanting to start with. Maybe you should make a poll and ask people what they think it would need to be done first.

All the people I know are badly wishing HL (HyperLoop) to be "alive" and available on iOS an Android. When I say "alive" I mean to be usable in a real world project, for both iOS and Android (sorry but windows doesn't matter, I'll come back to this later) I believe that most of the Ti devs are just like me, they know some javascript, they are able to read some native code, but they cannot build native apps. HL was the most amazing thing when it was demoed and even I was able to play with it and do some small stuff. Basically you suddenly were able to tap into the native SDK using JS, without the need of a cumbersome module. Then HL was forgotten (no android), HAL came out which I know only by name - and like me most of the Ti devs - windows platform showed up but clients are not interested into and we're stuck using Ti.Current

Please don't get me wrong (this is for Jeff and Appc guys) I know a lot of effort was put into HL/HAL and the windows platform, and I'm sure you had good reason to do it so I'm not disrespectful, but I just want to explain how many of us feel.

About windows, I have made tens of apps for clients, most of them consumer level, but also have enterprise clients and I have only ONE client that wants it for windows, ONE!

About Ti.Current - it's ok, of course it's ok, but HL was revealed with the little that it could do at that moments, and everybody started to feel miserable about how slow and cumbersome Ti.Current is compared with HL :)

So if there is something that you need to start with, then HL - or a similar solution like NativeScript - would be the thing, but for both iOS and Android. Anything else at this stage doesn't matter. ES6 ? come on, node js does it very good without ES6, layout system? this would be nice, but not for now, TiKit/Alloy...?

I'm 100% sure that if this basic layer would exist (and I repeat myself, in a really usable form for real world apps), the rest will come from the community. There are A LOT of devs that spent a lot of time building modules for Ti (Ben, Olivier, David, just to name some). There A LOT of devs that built widgets for Alloy, wrote tutorials or spent nights on QA. I'm sure that all these people will start writing the new TiKit or the compiler for Alloy or anything that's missing.

Also HL (or what name would have) would give access to all the JS devs like me to get their hands dirty with the native side of the platform in a very easy way. All the high level guys could concentrate in improving it and build really complicated stuff (like an adapter for cocoa-pods for example, or importing static libs) and all little guys would move pixels - aka build the simple UI elements for TiKit, and so on.

I know most of the you guys here and most of you also know me so if I said anything that might offend you, I apologise in advance. But I felt that I need to say what nobody said till now (or at least not publicly) and now that Appc seems to be really involved in Ti.Forward it seemed even more important to me.

[mattapperson]

I agree, and Jeff suggesting a Ti.Forward day will in large part help to lay this out in detail. Right now at a high level Ti.Forward is focused on getting HAL building for iOS and android, as well as documenting/supporting implementation on these platforms. After that we need to support a "metabase" that will map 100% of all native APIs to JS.

[cb1kenobi]

One of the first things we should do is get a CI server with daily builds of JavaScriptCore for each platform/arch (OS X, iOS, Android, Windows, and Window Phone). We need to keep our JSC up-to-date by merging every commit from WebKit, make sure our patches remain intact, and run the complete JSC test suite.

I'm afraid that if we don't automate this, our fork of JavaScriptCore will fall way behind as it did with Ti.Current and we'll paint ourselves into a corner. Our WebKit fork is currently 9 months behind. We're missing out on all the bug and security fixes and ES6 goodies. Plus nobody wants to sit there and download and compile JSC.

[yuchi]

I’ll try to answer @rborn from an higher level.

The challenge we have at hand is not specifically on the engineering side. What we’re trying to achieve here is a broader insight in the topics that need to be discussed for the future of the SDK as a whole. Most of those topics, while seemingly unrelated, are actually very tightly tied.

Take ES6 for example, as @cb1kenobi expressed here and in the related discussion (#8), any decision on this side has important fallbacks on how we’re going to integrate the runtime and how we’re going to build the (new?) pipeline.

Or take the layouting. This is fantastic engineering challenge because it gives us a deeper vision in which kind of UI patterns we’re going to dive in.

What about tooling? The success of a development platform comes from the constellation of tools that comes around it, without those a platform has value only for itself.

Packages and dependencies? Just look at the power npm has over the Node.js/iojs community.

Having access to the native APIs can be considered from an engineering standing point almost a solved issue. We have a new bridge, we have working prototypes of an automatic bindings generator (the ‘metabase’), we have other products that cloned our initial approach and looking good. What we feel now is that the solution is currently an half-assed one, and probably not the one that we actually need.

Building it all together will bring a shared knowledge and a wider understanding.

Back to the root of the discussion, a real roadmap will emerge in the next weeks, as we solve the smaller technical stoppers and we can start to flesh things out.

[rborn]

@cb1kenobi - this is a very good idea.

@yuchi Pier, I do understand all this, however I see the things a little different. Let me try to explain (this will sound rough, but I think someone has to say it :disappointed: ).

From the engineering point of view I understand all you wrote and I agree with it 100%. However, we're all engineers, that means we want to do everything perfect without being stressed by time and missing resources. There is one flaw in this mindset of us though: "Better is the enemy of done".

I'm only afraid that all this TiFwd effort which is great will be wasted. The very same happened with TideKit. I was there when all started, then at some point the team split: some wanted to make it work and other wanted to make it great. In the end the "great" team took the lead. TideKit got it's blog, tweeter, etc, and they started to build the platform to be great. they the wanted to make it awesome, and then they pushed hard to make it über-awesome...and there is no TideKit. Or maybe it is, but it's somewhere in a drawer forgotten by everybody.

We should learn from that. I bet the TideKit team are great engineers, but they failed by wanting to make the perfect product.

What you say above is great. But let's break it in pieces. ES6 - to cite some somebody "ES6 is a draft". There are nice things in it, (terrible too) and maybe speed improvements. But ES6 won't move your app at all if the underlaying engine doesn't exist (I'll keep naming it HL). Layout - yes, big challenge, but for now the Ti.Current layout it's just fine, it's not perfect, it's slow, it's broken for some cases, but it works, it exists and apps are made. So keep that and go on with HL so there is something to put the layout engine over. Tooling - sorry but CLI does it's job just fine. Studio never was an option, and if you think debugger Olivier's works ok. Npm - putting modules by hand it's ok - I'm not happy moving files either, but it's not stopping me in developing an app. So for now it's ok. And about node/io community? There is no community for TiFwd, sorry to say this, but there are 700.000 Ti devs out there that could be the community IF this gets through.

As you see above I said a lot of "it's ok" It is great? No. It's ideal? No. Can be done better? A 100 times.

But FOR NOW the solutions work and it's enough. No engineering trick, language sugar or tool will make your app start if there is no HL to start it.

Let me give you another example in the same line with TideKit about things NOT being where they could be (some people will hate me for this, and I'm sure I'm missing important things that lead to this situation) Again, don't want to offend anyone, I'm just trying to explain how things are seen from the normal user point of view.

We had HL1, Tony did the amazing Game of Life demo, the state of the project wasn't production ready but people could tinker with it, they could think on improvements, make PRs, etc.

All this WAS working on iOS, and we were waiting for the android build.

Then it started to iterate, to become "better and better", HL2, HL3... we lost track, the repos got less and less updated or moved to "underground", then we got some news about HL4, then there were rumours about an HL5...years passed, and finally the amazing HAL showed up.

I'll end all this "rant" about why I think all this with @mattapperson's words: ..."Right now at a high level Ti.Forward is focused on getting HAL building for iOS and android"

[rborn]

And I'll shut up from now on :)

[mattapperson]

@rborn first off, please don't shut up 😊

I think the important thing to remember Dan is that we have more then 1 working group going on for the simple reason that not everyone knows iOS, not everyone knows android, and not everyone knows C++. So with that in mind we are tackling more then 1 goal at a time. The other thing to remember is that we are starting discussions early so that when we are done getting HAL working on iOS and android we are ready to dig into the next task. And as for "let's not aim for the best but just get it working" I think most here could not agree more. There is a balance that says we don't want to keep tossing out effort because we made a mistake, but overall we agree. Our current community goal is 4-8months to have a working Ti.Next. We will know more and be able to provide a more solid date in the coming days and weeks, but that's our goal.

[infosia]

Hi guys, I just posted build script for HAL for iOS static library. I believe we want to keep using cmake to build/test HAL, I mean not building from Xcode, as long as it makes sense. Hope you enjoy it :)

https://github.com/appcelerator/HAL/pull/44

[Sophrinix]

Thanks @infosia

[jhaynie]

@infosia awesome.

[Sophrinix]

Now if we can get ahold of @joshthecoder so we can cmake script his HAL + android JSC work. Rumor has it that he has that working :)

[mattapperson]

Cool, thanks @infosia!