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).
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.
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.
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 for node-webkit; I've been having a blast messing around with it lately, it's great stuff. With the pre-built binaries, you can be off and running (with full node support in your browser JS) in minutes.
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.
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.
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.
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 :)
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.
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.
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:
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:
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.
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!
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) ?
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.
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.
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?
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?
AFAIK Air doesn't support Python, Ruby and PHP scripts inline in the local applications?
(Granted the language mixing code (called Kroll) is quite slow if you have large shared objects, but I've found with careful interface design you can mitigate the downsides and get a fast, stable interface, in my case mixing python modules like gzip and javascript.)
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.
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.
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.
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.
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 :)
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.
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).