Is TideSDK defunct?

Question

I am interested in creating a desktop application using HTML5+webkit, and I'd like to be able to build a stand-alone executables for various target platforms like a .exe file for Windows and a .dmg image for Mac OS. I have played around with node-webkit, which seems nice except for the packaging / distribution portion. I also stumbled on TideSDK, but that project seems to be inactive. For example, the latest release I saw was a beta from November of 2012. Yet, it seems the core developers have switched to developing TideKit instead.

Does anyone here know if TideKit is intended as a replacement for TideSDK? Is TideSDK going away? etc.

Answer 1

Well, TIDE is now officially a dead project. I just got this email about 15 minutes ago.

TideKit.com and TideKit have been discontinued.

TideKit was software for developing apps for all platforms simultaneously with a single base of code written in JavaScript.

The scope and complexity of the product made it difficult to assemble the platform all at once. This stemmed from a holistic approach to app development for all platforms. While creating a platform for JavaScript developers, much of the core engineering is in a variety of lower level languages that affect the speed of development. We considered delivering parts of our platform as we reached milestones, but this was not suitable for the start of trials.

We were widely criticized for not revealing our technical innovation in advance of our release. In a competitive environment, revealing advantages as you go can also mean assimilation as you go. We had already witnessed how quickly our technical advantages could be assimilated by competitors to our open source TideSDK product. Therefore, we held back with a view of delaying the duplication of features by competitors, increasing our technical barriers and working to protect our IP and business case until we felt we were ready.

In a startup, we talk about a Minimum Viable Product (MVP). In our case, our minimum viable product was much larger and more difficult to achieve. In total, approximately three years of research and development was committed with multiple developers working greater than full time hours. A factor that extended the development was an expansion of scope that aimed to lower friction in the app development process.

In Feb 2014, we created a system to queue developers with reservation system for the earliest possible access to TideKit. Our goal was to provide an early trial when it became available. Since the development itself was complex, we could not provide a date when ticket holders could start the trial process – but it would be following our betas, then moving forward as we scaled the platform.

We were clear with our language on the site concerning reservations. As a result, we expected little confusion about what was being purchased, our expectations of timing to market, or the terms of purchase for a reservation ticket. Purchasers were not paying for our product at this point, but for their position in a queue for a trial of our new technology. We also included a refund policy to ensure the terms of purchase for your ticket were available. The wait has been long, but not nearly as long as other difficult engineering challenges including Myo that pre-sold their product and were also delayed before successfully rolling out.

Throughout the development cycle we provided updates of our status via posts roadmap page, email to our ticket holders and communications on our social channels. We did our best as a team to open ourselves to questions and maintain a social presence.

At the end of May 2015, we communicated our strategy to execute a series of focused betas that would have seen the platform revealed publicly and incrementally. We were at a stage that parts of the platform needed developer feedback as we rolled these out consecutively.

In the days preparing for our first public beta, we recognized the extent to which our brand had been poisoned by our timing to market. A campaign of negativity that had begun several months earlier with followers and ticket holders had taken its toll on our team, brand, and business.

We believed the beta releases would soon bring an end to the negative talk. On July 8 and 9 we faced further eruptions on social media that reached the tipping point. With the discussion no longer about the product nor its future, this was far more serious.

We failed to bring the product quickly enough for you. As a result, we came to the serious decision to discontinue TideKit and dissolve our company.

We wish to thank everyone involved that worked on the product and with our team. This includes businesses, entrepreneurs and supporters of our vision for app development.

Your TideKit Team

Answer 2

you are right, TideSDK is aging and pretty inactive today. And you're also right, we as a core team completely focus on TideKit now. TideKit is the future!

If you want to know the full story about why we stopped working on TideSDK and started TideKit, I recommend you to read our first Q&A. There you'll also find an answer about how we compete with node-webkit:

https://blog.tidekit.com/post/your-questions-our-answers-01

We've just reached the highest HTML5 score any app development platform ever achieved. If you want to know more about builds, like the ones you mentioned for Windows and OS X, you should read this

Desktop Builds https://blog.tidekit.com/post/from-a-desktop-perspective-tidekit-for-tidesdk-developers

Answer 3

There is a new kid on the block for this sort of projects: atom-shell Based in nodejs and used to create the great Atom editor

Technical differences with node-webkit: https://github.com/atom/atom-shell/blob/master/docs/development/atom-shell-vs-node-webkit.md

Presentation at JSLA about "Native NodeJS Apps": http://vimeo.com/97881078

Answer 4

If you look at this blog post, they talk about how unsustainable the economical situation is

http://www.tidesdk.org/blog/2013/04/11/tidesdk-in-numbers/

and I can't find the tweet that was stating the reasons behind the transition from one project to another. But I guess that the blogpost speaks for itself.

Anyway, I'm delivering a project written in node-webkit ( because I starded on Tide but for the obvious reasons I had to switch ) and I'm using grunt for packaging and in the end is not that bad.