SapphireSteel Forum
Welcome, Guest. Please login or register.
May 23, 2013, 02:27:44 AM

Login with username, password and session length
Search:     Advanced search
Welcome to the SapphireSteel forum - for discussion of the Ruby In Steel and Amethyst IDEs
3884 Posts in 800 Topics by 669 Members
Latest Member: m
* Home Help Search Login Register
+  SapphireSteel Forum
|-+  General
| |-+  Amethyst
| | |-+  Do I take the plunge ? help with a buyng decision
« previous next »
Pages: [1] Print
Author Topic: Do I take the plunge ? help with a buyng decision  (Read 1226 times)
amiracam
Jr. Member
**
Posts: 69


« on: February 10, 2012, 11:47:23 AM »

I have actually a few project tracks where the general platform will be Ruby i.e. the underlying language , mostly services oriented architecture relying on Sinatra, perhaps some Admin consoles in Rails/Sinatra, persistence with NoSqls e.g. MongoDB but to cut to the chase, I do have a fat client component and for there I do want tools. Stuff like what I"m used to in VisualWorks Smalltalk  i.e. real robust GUI building, debugging support needs to be good and of course the language needs to be productive. I am considering JRuby for the fact that it makes Swing palatable but I have worked with Swing and it gives me the hives. I have considered some of these JS desktop building tools/frameworks as well but I'm more inclined to use something that has been around for a while and have strong support from a community or corporation so that's where Flex comes in.  Frankly, besides doing some Flash work a few years back I don't know enough about it and I'm confused as to whether Flex is on its way out or not with advents such as Html5, Apple's animosity towards it and I guess Adobe.

Here are my requirements for whether I do go for Flex and what  tool I invest in:

1. Easy to use GUI builder
2. Good debugging support a "edit and continue" feature would be fantastic.
3. I will primarily keep the "fat" client "thin" , so REST /JSON support would be good.
4. Ability of calling local Ruby code from I guess ActionScript would be very useful and I don't mean via REST in this case i.e. some clean FFI
5. Ability of creating executables that can run "AIR"
6. Ability of deploying GUI based apps onto Windows and Mac which I understand AIR can do. Also on mobile contexts i.e. iOS and Android
7.Ability of developing both on Mac and Windows would be a very nice to have.
8. I should be able to at runtime generate visual components.
9. Reasonably priced.
10. Brief rundown on the advantages for using Amethyst instead of Adobe's Flex Builder


I appreciate the feedback. thanks
Logged
Dermot
Administrator
Hero Member
*****
Posts: 1005


« Reply #1 on: February 13, 2012, 10:33:15 AM »

There isn't a simple yes/no answer to your questions, but I'll give it a shot. But be aware that I have no knowledge of what Adobe are up to and that some of the things for Amethyst/Ruby haven't yet been implemented

So, on Amethyst vs FlashBuilder (FB): FB was designed to support Adobe's Flex platform and with that going away from Adobe, they now have no incentive to develop it further. They've said that they will release another version (with I guess what they've got in the pipeline included) but as for any further development ... ?? I just can't see that Adobe can make any money from FB, so you might want to draw your own conclusions about that. Also, it's worth pointing out that Adobe have decided to drop any GUI designer support from the next version of FB. See here: http://www.itwriting.com/blog/5240-adobe-discontinues-flash-catalyst-clarifies-flex-and-flash-builder-futures.html

On deployment: Amethyst does support build deployment into Android and iOS, but we haven't updated the scripts for the latest AIR and Android SDKs. If there's a requirement for this (and to be honest, we haven't been overwhelmed by requests for deployment features) we'll upgrade. The mechanism is there (it's part of the MSBuild system that we've implemented) and it won't take much to bring it up to date.

On calling ActionScript from Ruby: we're working on that. As you know, we've got both Ruby and ActionScript development environments and it's one of our primary goals to bring the two much closer together. One of the things that Ruby is sorely lacking is a front end (there's some GUI stuff in the Ruby libraries, but it's nowhere near usable, IMO). I don't want to say more until we've got something working and demonstrable, but being able to drive a Flash front end from Ruby is a high priority.

Amethyst vs. FB: well, (as a totally unbiased observer), I'd say that Amethyst has a future. We are absolutely committed to it and it forms the fundamental basis of what we do. In fact, we're currently re-engineering all our Ruby code to use the Amethyst code base. In contrast, I'd have to say that I don't think FB is in any way fundamental to Adobe ... they might continue to develop it or they might not. Either way, it will make no difference to them ... on the corporate radar screen it's hardly a blip: for Adobe, it's Flash CS5 that's the real money maker. Functionally speaking, Amethyst has a better debugger (and our new debugger 'bubble' system is miles ahead. However, FB has been around longer and has better integration with other Adobe products. Otherwise, they are pretty similar ... except that Amethyst is Visual Studio based and FB is Eclipse based. If you like Eclipse go for FB, if you like VS, go for Amethyst.

On the visual designer ... in contrast to Adobe, we think that visual design is important. We're currently reworking our designer to incorporate all the lessons we've learnt from our first go (which even in its current state is a lot better than Adobe's) and this new designer will form the basis of both Amethyst and Ruby visual design.

AIR ... we're not quite up to date with the latest Adobe AIR SDK (I think we're on 2.6), but again if there's a demand we can produce an Amethyst that will work with the latest AIR SDK.

On the Mac, we're looking at that and we aim to work (that is, debug and deploy) seamlessly across iMac, iOS and Windows. Clearly, we are fundamentally Visual Studio based  and that isn't going to change, so all development will have to be done on Windows via VS. We're not in the business of building core IDEs.

Dermot
« Last Edit: February 13, 2012, 10:47:21 AM by Dermot » Logged
amiracam
Jr. Member
**
Posts: 69


« Reply #2 on: February 13, 2012, 11:19:12 AM »

Dermot:

thanks for the complete response. Yeah, Adobe dropping Flex is sort of a game changer i.e. honestly since lately I have been bouncing back and forth between Windows and the Mac being able to run the IDE in both platforms is really convenient which I can't do with VS unless I run on Parallels. Now, I'm not sure what to do. A visual designer is a must. My immediate needs don't target iOS or Android but I have plans for that and it seems you don't have any definite plans in the near future i.e. within say 6 months to release support for that. Although , I guess I'm confused as to what you "won't" support i.e. if I compile to swf I should be able to run on any Flash player (versions aside) and if compiled to .air on the AIR runtime. I guess you mean you won't have an automated mechanism to deploy to a target devise ?

I will never have to just only do Mac development  so if I had to I guess I could confine myself to running on Windows for GUI building on Amethyst I may do that.

I have been having issues with RiS, I wonder if its because I have the free VS shell but I need to get past those on RIS before I even start evaluating Amethyst. I hope not since I don't want to drop the major cash required to buy a full version of VS.

-Charles
Logged
amiracam
Jr. Member
**
Posts: 69


« Reply #3 on: February 13, 2012, 11:59:36 AM »

Dermot:

Just been out checking out Adobe's move to open source Flex, from their press releases they seem to be saying that html5 will be the way to go . I think Apple finally pushed them over the edge. That really sucks , I need to build desktop apps i refuse to do them with Swing, sure Flex will probably be around for a few years but it seems that Adobe will concentrate on html5 and put Flash to pasture.

Logged
Dermot
Administrator
Hero Member
*****
Posts: 1005


« Reply #4 on: February 13, 2012, 12:29:17 PM »

A couple of points ...

1) You have to make the distinction between Flash and Flex. Flex is going away (at least from Adobe), Flash most certainly isn't. Adobe completely screwed up in their presentation and execution of the Flex/Flash announcement. You have to go back a bit in time to understand this. In version 3 of Flex, FlashBuilder was called FlexBuilder and was clearly targeted at Flex. Then in Flex4, Adobe changed the name to FlashBuilder, I would guess in the hope of persuading people to buy it. It didn't work. But when they decided to kill off Flex, they accidentally gave the impression that they were killing Flash - because they had intentionally mixed the branding of the two. I don't think they are killing off Flash at all, and they've been trying to make this clear ever since. What they are saying is that HTML5 is the way forward for what Flex now does (complex forms and content). On the other hand, Flash is going to be around for games and the like for a long time. Now, it turns out that Flash also included the facility for buttons, combos and so on - totally independently of Flex. In fact, we were a bit astonished to find that a Flash button is a completely independent thing from a Flex button (and even more confusing, a Flex 3 button is a different thing from a Flex 4 button  - go figure). Our new designer is concentrating on Flash and we're intending to connect a Flash front end to a Ruby back end.

2) We already support both iOS and Android AIR distribution - you can build and distribute iOS and Android apps already with Amethyst, but we're waiting to see where Adobe is going with AIR before we do anything more significant.

Dermot
Logged
amiracam
Jr. Member
**
Posts: 69


« Reply #5 on: February 13, 2012, 12:51:12 PM »

just to be clear, I'm also interested in having a Flash front end (built with a visual designer) communicate with local ruby code because there is a case for business logic that goes beyond simple form validation where I would prefer that written in Ruby. As far as communicating  a Flash front end to a ruby server and in my case I lean towards the leaner Sinatra, I would just expect to be able to REST and use either xml or json and that should be an easy enough feat.
Logged
Pages: [1] Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!