

Create multi-platform desktop apps with HTML5, CSS3 and JavaScript - kushsolitary
http://www.tidesdk.org

======
fairwinds
Titanium was transitioned to TideSDK in early 2012. At this point the code
lacked support for any modern operating system other than Windows 7. Ubuntu
and OSX support for any current versions of these OS's did not yet exist.

The challenges involved in moving forward with the code base from the previous
maintainer were documented in this post:

[http://www.tidesdk.org/blog/2012/11/16/1-dot-3-1-beta-
releas...](http://www.tidesdk.org/blog/2012/11/16/1-dot-3-1-beta-release-
announcement/)

The work has been steady and ongoing. The software itself is complex and
substantial progress has been made. More that 1 million line changes of code
were made to end of Dec, 2012.

This kind of investment and involvement in this project has been huge for us.
It is certainly deeper than the rebranding and documentation effort that we
also undertook as part of the project.

TideSDK became an affiliate project of Software in the Public Interest (SPI)
in October, 2012. As part of this non-profit organization, we stand together
with other significant and substantial open source projects (including
Postgres, Drupal, Debian, Jenkins, ArchLinux) that are under the non-profit
administration of the SPI.

Tens of thousands of developers now discovering TideSDK as a result of our
efforts. This number is steadily increasing. Ongoing upgrades and fundamental
code changes in the sources are leading to an amazing solution.

Commercial developments involving TideSDK are also underway for many.
Obviously, despite the surge in mobile use, desktop development is
comparatively smaller. That said, there remains an important need to address
for the desktop that TideSDK is filling.

We've put plenty of effort into establishing community around TideSDK as well
and to make resources available to developers:

Documentation: <http://tidesdk.multipart.net/docs/user-dev/generated> Source
Code: <https://github.com/TideSDK/TideSDK> Tutorials: Get started easily
[http://tidesdk.multipart.net/docs/user-
dev/generated/#!/guid...](http://tidesdk.multipart.net/docs/user-
dev/generated/#!/guide) Q & A on Stack Overflow: Get help
<http://stackoverflow.com/questions/tagged/tidesdk> Report a Bug: Help us
improve <https://github.com/TideSDK/TideSDK/issues>. IRC: Chat with us on
#tidesdk on freenode.net Twitter: Follow TideSDK @tidesdk. Blog: Read our blog
at <http://tidesdk.org/blog>. Knowledge Base: Read the wiki
<https://github.com/TideSDK/TideSDK/wiki> Google Groups: Join our mailing list
<https://groups.google.com/forum/#!forum/tidesdk>.

In addition, more great things are coming this year as the result of our
involvement with TideSDK. The core talent behind TideSDK formed
<http://coastalforge.com> to bring services and support. We've also got an
amazing new solution to reveal shortly that has been spawned from our work.
More on these efforts quite soon.

David Pratt TideSDK Project Lead

~~~
wturner
If I write a project that uses the web audio api and then package it up as a
desktop Mac (or other OS) app with tidesdk, will it work?

------
jakozaur
Great project!

The only minor thing that disturbes me are a few well-known logos (Atlassian,
GitHub) beyond "Thank you". I know it is a grey area of ethics, but perhaps we
should encourage to put real partners (clients, etc.). If you quickly scroll
you may see it as more impressive, but in long run listing that kinds of acts
seems unprofessional (e.g. listing Microsoft as major partner, when you just
license their software).

~~~
fairwinds
Our thank you on our landing page is not about identifying partners. It is an
expression of our thanks for organizations that have helped us by donating
software or services to allow us to continue developing TideSDK. Hope that
helps to clarify this.

------
mappu
I've been meaning to build something like this using CEF or something, and i'm
glad someone else beat me to it. And it has TCP sockets! That seemed like such
a glaring omission in cordova/phonegap.

I also think it's good to provide a platform.getOSType() in a cross-platform
environment as long as things don't get out of hand. You could switch on this
to load the platform's default fonts.

~~~
toni
Try node-webkit[1]. It's a chromium wrapper around nodejs and they have
various ready-made binaries for linux/osx/windows platforms. In my experience,
it's much cleaner and faster to get up and running than titanium/tide

[1] <https://github.com/rogerwang/node-webkit>

~~~
_neil
I've been following node-webkit and AppJS on github for a while and they both
look great, though I haven't actually used them. Maybe (hopefully) I'm wrong,
but it doesn't seem like you can compile an app to a standalone binary with
either; specifically on OSX.

~~~
toni
By "... compile an app to a standalone binary", do you mean that you would
like node-webkit/appjs to convert your HTML5/JS files to ObjectiveC? That
would be really amazing, but this is just like phonegap/cordova. It basically
shields your files around a webkit wrapper.

~~~
_neil
I mean being able to compile to a .app file on OSX, .exe on windows, etc.
TideSDK can do this in a wrapper-type of way like you mentioned.

~~~
toni
Yes, node-webkit does that too. Check out: [https://github.com/rogerwang/node-
webkit/wiki/How-to-package...](https://github.com/rogerwang/node-
webkit/wiki/How-to-package-and-distribute-your-apps)

~~~
fairwinds
TideSDK handles the packaging and bundles everything into packaging native to
the platform. You don't have to worry about what to include because it is
gathered and packaged for you.

------
mitalvora
The wiki page on the github provides list of examples using TideSDK.

[https://github.com/TideSDK/TideSDK/wiki/Applications-
Using-T...](https://github.com/TideSDK/TideSDK/wiki/Applications-Using-
TideSDK)

Apart from that there are examples available to checkout from the repository.
(develop branch) <https://github.com/TideSDK/TideSDK/tree/develop/examples>

We are working on fixing various issues including moving to latest webkit.

------
tehwalrus
Thank you very much for updating this after Appcelerator dropped it.

I have written quite a few tools using this system (HTML5/JS, with a little
help from a couple of python modules) and I was furious when I updated the
Titanium build tools to find out that desktop mode had been dropped and I
could no longer build cross-platform installers!

I have been editing the HTML code _inside_ my .app folders on OS X while
waiting for this to come out - I'll install it ASAP and see what I can get
working again :)

------
muyuu
I was looking for examples or a gallery of sorts, but couldn't find anything
other than this:

<https://github.com/TideSDK/TideSDK/wiki/TideSDK%20Samples>

And maybe in this tutorial that I didn't have time to finish yet:
<http://www.youtube.com/watch?v=2ikb-4tdygg>

Looking forward to give it a shot.

~~~
fairwinds
Here is a recent example in production with shopify

[http://www.shopify.com/technology/6825262-shopify-desktop-
th...](http://www.shopify.com/technology/6825262-shopify-desktop-theme-
editor-1-0-release)

------
djla
This looks like it's based on Titanium, which I've used before and they
basically stopped supporting the product for Desktop applications... weary of
starting another project using this. Last time I had to convert everything
over to an Adobe AIR wrapper with a HTML control.

[http://developer.appcelerator.com/blog/2012/01/the-future-
of...](http://developer.appcelerator.com/blog/2012/01/the-future-of-titanium-
desktop.html)

~~~
vidarh
What makes you weary of using it? This project looks like it's demonstrated
quite well that they were able to cleanly take over where Appcelerator left
off, with a degree of cooperation from Appcelerator.

~~~
baggachipz
Wary. Wary of using it. Unless using it actually tires his body/mind to the
point of exhaustion.

------
polshaw
Very interesting.. can anyone comment on the differences between this and
node-webkit/adobe air/appJS ??

Can source code (ie. JS) be completely private (ie could not be reasonably
accessed by a competitor?)

Does it have 'custom' jumplist support on windows (eg. media player buttons)?

Global hotkey support??

------
rhengles
I wanted to build a simple tool for personal use some time ago, and wanted to
make it a desktop app in JS. I evalued many options, but I wanted a native
look&feel, and with a comprehensive API. In the end I chose Mozilla Rhino+SWT,
it really satisfied me. I'm waiting for Nashorn!

(edit: typo)

------
Gmo
Care to comment how this compares to (Mozilla) XulRunner ?

Well, for one thing, I did not find any decent script to easily package a
XulRunner application, so maybe that's a plus point for each, but anything
else worthwile (apart from the fact it's based on WebKit) ?

------
MaxGfeller
I find it weird that the only sample application built with it is the old
Wunderlist. Wunderlist 2 - which was released a few weeks ago - was developed
native for each platform.

~~~
fairwinds
Perhaps it may seem so. That said, the original Wunderlist was likely the most
infamous use of the original technology that reached millions of users.

It's no slight against its makers to have gone purely native but the fact is
that most companies developing a todo app do not have millions in investment
or the sort of native programming capacity to throw at this kind of project.

TideKit is a solution that is going to get you on all platforms quickly and
its only improving over time. As you might be aware, the new Wunderlist 2
seemed to have lost its linux support as a result of their recent shift.

We're hoping to show something quite soon that shows a speed and quality of
development that will have most wundering why they transitioned to native.

~~~
onetwothreefour
I think what the guy you're replying to was saying is that the entire page
seems to be about Wunderlist, when they no longer use this SDK, and their use
of it isn't really that complex.

Perhaps it would be better to show some actual users with a carousel type
thing?

------
smagch
I'm really interested in this project. Multiplatform desktop app with HTML5 is
really attractive over Qt and Adobe Air. Does anyone have a experience with
XUL or node-webkit?

------
bbayer
Can anyone explain what is the difference with Adobe AIR?

~~~
kushsolitary
You need to install Adobe AIR in order to run the apps created for AIR but for
TideSDK, you don't need any additional software.

~~~
toni
You need to install Tide runtime once (just like AIR) to be able to run Tide
apps.

------
Feeble
We made a quick spike locally in the office. Like the idea but seems to be
based on a two year old webkit and only gets a score of 202 in html5test.com.

~~~
_neil
It seems [1] they are updating to trunk in 1.4.0, whenever that happens.

[1] [http://stackoverflow.com/questions/13598319/questions-
regard...](http://stackoverflow.com/questions/13598319/questions-regarding-
appjs-tidesdk) (4th paragraph)

------
ww520
Looks good. Does anyone know what is the monetization approach for this kind
of apps in the mobile platforms?

------
TazeTSchnitzel
Screenshots from Windows Vista? Why not Windows 7 or Windows 8?

------
ryanicle
This is nicely done! Awesome project!

------
binarycheese
like I always say: "Write in one language, suck on all platforms"

But it is a good start

------
WayneDB
For anyone looking to use native UI components and not HTML/CSS/JS, take a
look at these two which seem to be growing rapidly:

<https://github.com/picoe/eto>

<https://github.com/mono/xwt>

~~~
polshaw
These lack the real advantage of HTML/CSS/JS apps though, which is that you
can make one responsive app and package it for all desktop _and mobile_
platforms.

~~~
WayneDB
I'd like to see the code-base for a serious application front-end that covers
both desktop and mobile because I don't think it's a viable solution for
anything more complicated than a TODO list. What successful products can you
point to that do this well and are you aware of the pains that they went
through to ship?

Although mobile platforms are being added to Eto, I don't think I'll ever want
to build the same UI for desktop and mobile. That's just me though.

~~~
polshaw
Ehh.. i'm making one (depending on your definition of 'serious'.. it's no
office or photoshop of course).

It is responsive, so it is not the 'same' UI, but with a convergence of
laptops and tablets coming from both sides (android and windows), the
separations make decreasing sense (eg denying desktop users touch
functionality, or android users high-res/mouse/keyboard). Yes, there have been
_lots_ of pains.. but using something like this so that you only have to
target (known version of) webkit at least removes some of the issue. The jury
is still out on whether it was a wise decision (I would have had to learn
obj-c/java/at least one desktop UI framework, as well as develop and maintain
at least 2/3 code-bases, so it likely would have been a similar nightmare),
but i'm far enough down the line that the likelihood is it will stay that way
(concern re: code theft is the only reason i don't say definitely).

There are quite a few apps that could be made that require not much more than
a sophisticated todo-list UI though. A calendar app might be one off the top
of my head that would benefit from a responsive UI.

~~~
WayneDB
The separation makes sense to me because of screen real-estate. On a tiny
screen, there's only so much functionality that I want to offer in one single
view. To your other point, Eto and Xwt ride on top of .NET/Mono which is
stable and current, so you only need to learn one language and then you can
address native widgets, even a WebBrowser component. Think of the
possibilities...the whole embedding a browser in a native window has been done
many times, but how many of those kits let you render native elements too?

Neither of these kits have a complete mobile story yet (I don't even think Xwt
team is working on one). So, I'm not saying that any of this is useful for
anyone with a same-view-code-for-mobile requirement, but I think it could be
really soon. The Eto guys are working on the iOS backing and they already have
some impressive demos running on each of the major target desktop platforms
from a single code-base. Anyway, I just like them sorry for hijacking :)

~~~
polshaw
No hijacking, it's good to hear others' opinions. Tend to learn a lot from
(software) discussions here. The thread is dead effectively for a while anyway
now.

The way i see it, a minimum expectation (for 'universal' coverage scenarios)
is: windows, iOS, android. Perhaps OSX too. There are cross platform solutions
for the desktop, but that would still require 2 extra versions to cover the
minimum standard. Soon you might be able to do iOS with Eto, but until it gets
android support that would mean you still need to implement the mobile UI
twice and port the backend code at least once (a feat that i thought was
harder when i started than i do now; but maintenance would still be hell).

So you might lead to the idea of doing a cross-desktop app and a webapp with
phonegap etc for mobile. This allows you to support more platforms (WP7/8,
FFOS, BBx, ubuntuPhone?). Tablets are going to want a more in-depth UI than a
phone, so then you have 2 layouts.

By the time you have a flexible layout system, adding a third may even sound
preferable to porting everything to .NET, even if you are familiar with it!
Yes you want extra features such as keyboard/mouse support, and more in-depth
editing etc, but you _do_ get the nice bonus that your android app will have
those too (benefiting stuff like the transformer prime), as well as keeping
all touch function on the desktop where touchscreens are taking off-- that
probably wouldn't seem worth adding if it were a separate desktop app (same
for smaller window-sizes). It's very reassuring to know that almost any
feature implemented should work across all platforms. You could even extend a
basic version for PS3, wii, TVs, chromeOS etc without too much trouble.

There are definitely shortfalls; lack of code privacy, still some browser
issues on the mobile side (scrolling?), the DOM sucks, localStorage is tiny,
etc! Phone processing improvements are fast whittling away at performance as
an issue for many types of basic app though. IMO neither method (HTML vs
'native') are there yet, and different apps will suit each approach. To me
cross-mobile/desktop apps are the future, although i concede that it isn't
practical (or possible) for a lot of use cases today.

