RE: [flexcoders] Newbie: Flash vs. Flex, CPUs, Lazslo

2005-04-29 Thread Erik Westra
An example would be Remoting, any here who have used Flash 
Remoting in IDE form know its more tedious to implement then 
FLEX. 

I don't have this problem, but that may be because we internally use our
own remoting components.

On all other point I agree with u. We chose flex for another importend
reason: the component framework. Allthough I personally don't like the
V2 components, macromedia uses them in Flex and will continue to develop
them. They are with a large team wich is capable of managing such a
component library. We could develop components ourself wich would be
half the size and more optimized, but the developing takes a lot of time
and getting them completely bugfree would not be doable.


Greetz erik


-Original Message-
From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Scott Barnes
Sent: vrijdag 29 april 2005 3:00
To: flexcoders@yahoogroups.com
Subject: Re: [flexcoders] Newbie: Flash vs. Flex, CPUs, Lazslo

On 4/29/05, Jim Schneider [EMAIL PROTECTED] wrote:
 1. Could someone explain (or point me to a doc/faq) that tells me why 
 I would choose Flex over Flash. What can Flex do that Flash can't? 
 Even if it's more difficult in Flash, perhaps it's worth it given the
cost of Flex.

I'll take a stab at this one.

As a Flash IDE developer for many a year, I've found that its really a
bottle neck and a slow process at times. Flash IDE takes a lot of
discipline and understanding of the concept of flash itself and you
better be armed before taking on a large project.

When developing in large projects you tend to be a one man show, as to
share resources or code amongst other developers takes a lot of
communication and patience. That alone improves why FLEX is a valid
purchase.

As for what can FLEX do FLASH can't? not much technically as FLEX is
really an alternative approach to the end goal. It does bring a lot more
to the table then FLASH IDE in terms of Rapid Development. An example
would be Remoting, any here who have used Flash Remoting in IDE form
know its more tedious to implement then FLEX. Its examples like this
that change your perspective on FLASH vs FLEX.

On top of that, FLEX handles a lot of your tasks for you, things like
initialization modals, busy cursors, history management etc are all
automated tasks within FLEX.

In terms of costs, i've seen soo many projects take months to do
what could be done in FLEX in half the time. These are also run by some
very competent FLASH developers who have years of experience and know
the language/tool off by heart. Its just cumbersome, slow and at times
very tedious.

That being said, you do a lot more control visually / debugging wise in
FLASH IDE then you currently at present have in FLEX. On top of that
your portability is much more open then at present with FLEX.

Implementing Runtime Shared Libraries in FLASH IDE is awful and painful,
just ask JessterXL all about that one, he's mastered it but he went
through a learning curve and pain to get to that point. I like wise, i
think i've got it mastered but found it took a lot of imagination and
research.

In FLEX? bah its next to easy as implementing a Tree component.

In FLASH MX 2004 Pro, implementing even a Tree component (databinding
aside) isn't a simple task and requires some extra work then compared to
FLEX.

Cost wise, you'll blow more money using FLASH IDE then you will via FLEX
for a large application.

If you are building a small RIA app that isn't as large and doesn't
require a team of developers to work on, then yes FLASH MX 2004 Pro is
the suitable resource.

 2. Speaking of cost, I read on MM's site that they recommend a typical

 deployment of a Flex app have 6 - 8 CPUs. Is this true in practice? If

 I have an app that has 50 users (would grow to perhaps 10K users) who 
 don't hit the system very hard, what are CPU requirements? Are there 
 any performance benchmarks that I can use as a guideline for what I 
 would need initially and at what point I would need to upgrade. As a 
 small company, we can probably chew off $12K, $70K is another story 
 (unless I misunderstand the licensing).

Not sure on server-side, i've oftend wondered that my self and while
i've read various optimization techniques and resources i'm still
skeptical of its use in terms of high volume. That being said, we could
easily use a DUAL CPU setup here at work for a FLEX application (approx
300-500 end users hitting it daily) and provided there is enough ram
thrown at it, it should hold up fine. If need be i'd look into
clustering the servers or throwing more RAM at it. I've FLEX Server
tends to have ok automated garbage collection and simply apply the same
server-side rules as i do with a CFMX server.

 3. Has anyone had any real-world experience/lessons-learned with 
 Laszlo and any comparisons with Flex?

I've gone down the path of using Laszlo as a prototype concept,
comparing it to FLEX? In many ways the XML flavour Laszlo brings to the
table is more simplistic

[flexcoders] Newbie: Flash vs. Flex, CPUs, Lazslo

2005-04-28 Thread Jim Schneider
1. Could someone explain (or point me to a doc/faq) that tells me why I
would choose Flex over Flash. What can Flex do that Flash can't? Even if
it's more difficult in Flash, perhaps it's worth it given the cost of Flex.

2. Speaking of cost, I read on MM's site that they recommend a typical
deployment of a Flex app have 6 - 8 CPUs. Is this true in practice? If I
have an app that has 50 users (would grow to perhaps 10K users) who don't
hit the system very hard, what are CPU requirements? Are there any
performance benchmarks that I can use as a guideline for what I would need
initially and at what point I would need to upgrade. As a small company, we
can probably chew off $12K, $70K is another story (unless I misunderstand
the licensing).

3. Has anyone had any real-world experience/lessons-learned with Laszlo and
any comparisons with Flex?

Thanks

Jim





 
Yahoo! Groups Links

* To visit your group on the web, go to:
http://groups.yahoo.com/group/flexcoders/

* To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

* Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
 





Re: [flexcoders] Newbie: Flash vs. Flex, CPUs, Lazslo

2005-04-28 Thread Scott Barnes
On 4/29/05, Jim Schneider [EMAIL PROTECTED] wrote:
 1. Could someone explain (or point me to a doc/faq) that tells me why I
 would choose Flex over Flash. What can Flex do that Flash can't? Even if
 it's more difficult in Flash, perhaps it's worth it given the cost of Flex.

I'll take a stab at this one.

As a Flash IDE developer for many a year, I've found that its really a
bottle neck and a slow process at times. Flash IDE takes a lot of
discipline and understanding of the concept of flash itself and you
better be armed before taking on a large project.

When developing in large projects you tend to be a one man show, as to
share resources or code amongst other developers takes a lot of
communication and patience. That alone improves why FLEX is a valid
purchase.

As for what can FLEX do FLASH can't? not much technically as FLEX is
really an alternative approach to the end goal. It does bring a lot
more to the table then FLASH IDE in terms of Rapid Development. An
example would be Remoting, any here who have used Flash Remoting in
IDE form know its more tedious to implement then FLEX. Its examples
like this that change your perspective on FLASH vs FLEX.

On top of that, FLEX handles a lot of your tasks for you, things like
initialization modals, busy cursors, history management etc are all
automated tasks within FLEX.

In terms of costs, i've seen soo many projects take months to do
what could be done in FLEX in half the time. These are also run by
some very competent FLASH developers who have years of experience and
know the language/tool off by heart. Its just cumbersome, slow and at
times very tedious.

That being said, you do a lot more control visually / debugging wise
in FLASH IDE then you currently at present have in FLEX. On top of
that your portability is much more open then at present with FLEX.

Implementing Runtime Shared Libraries in FLASH IDE is awful and
painful, just ask JessterXL all about that one, he's mastered it but
he went through a learning curve and pain to get to that point. I like
wise, i think i've got it mastered but found it took a lot of
imagination and research.

In FLEX? bah its next to easy as implementing a Tree component.

In FLASH MX 2004 Pro, implementing even a Tree component (databinding
aside) isn't a simple task and requires some extra work then compared
to FLEX.

Cost wise, you'll blow more money using FLASH IDE then you will via
FLEX for a large application.

If you are building a small RIA app that isn't as large and doesn't
require a team of developers to work on, then yes FLASH MX 2004 Pro is
the suitable resource.

 2. Speaking of cost, I read on MM's site that they recommend a typical
 deployment of a Flex app have 6 - 8 CPUs. Is this true in practice? If I
 have an app that has 50 users (would grow to perhaps 10K users) who don't
 hit the system very hard, what are CPU requirements? Are there any
 performance benchmarks that I can use as a guideline for what I would need
 initially and at what point I would need to upgrade. As a small company, we
 can probably chew off $12K, $70K is another story (unless I misunderstand
 the licensing).

Not sure on server-side, i've oftend wondered that my self and while
i've read various optimization techniques and resources i'm still
skeptical of its use in terms of high volume. That being said, we
could easily use a DUAL CPU setup here at work for a FLEX application
(approx 300-500 end users hitting it daily) and provided there is
enough ram thrown at it, it should hold up fine. If need be i'd look
into clustering the servers or throwing more RAM at it. I've FLEX
Server tends to have ok automated garbage collection and simply apply
the same server-side rules as i do with a CFMX server.

 3. Has anyone had any real-world experience/lessons-learned with Laszlo and
 any comparisons with Flex?

I've gone down the path of using Laszlo as a prototype concept,
comparing it to FLEX? In many ways the XML flavour Laszlo brings to
the table is more simplistic but at times limiting. FLEX also offers a
much sweeter options in terms of packaging applications and say
integrating with CENTRAL. On top of that its Flash Remoting
capabilities from memory weren't there and keep in mind it's based on
FLASH 5 which also means a reduction in flash technology advancements
(6 had a significant increase in features alone)

I've found Laszlo also to be 3 steps behind FLEX/FLASH IDE itself. It
feels like they are simply picking up the bread crumbs and if anything
i'd rather look at the XAMLON in terms of FLEX alternatives - mainly
as i see that as being the darkhorse in the race for XML UI creation
;)

Hope i helped? or just ranted... heh.

-- 
Regards,
Scott Barnes
http://www.mossyblog.com
http://www.flexcoder.com (Coming Soon)


 
Yahoo! Groups Links

* To visit your group on the web, go to:
http://groups.yahoo.com/group/flexcoders/

* To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

* Your use of Yahoo! Groups 

Re: [flexcoders] Newbie: Flash vs. Flex, CPUs, Lazslo

2005-04-28 Thread JesterXL
Scott hit just about everything.  I'll just repeat it anyway as short as 
possible; feel free to ask for further clarity.

1. Flex allows you to develop form based, web 'esque applications faster 
than you can do in Flash.  You have a better, more mature component set, and 
layout is automatically done for you.  All files are ASCII vs. the closed 
binary format you create in Flash (FLA), which makes it easier to edit. 
Additionally, all classes are created for you vs. in Flash you have to merge 
these with visual objects that have nothing usually to do with coding 
controls.

That's why I like it vs. Flash, and I converted to using Flash full-time at 
Flash 5, 2001 from Director.  I'm trying to convert to Flex for anything not 
related to mobile development, games, or designer 'esque sites/applications.

2. Don't know, I develop fat client applications, and my server is usually 
handled by another team member, and our servers aren't pounded.

3. No, nor do I want to.  Lazlo's features do not sound appealing, such as 
Flash Player 5 output (I heard recently they supported 6 and 7 supposedly). 
The attitude for Lazlo was XML layout, but I have heard hide nor hair as far 
as accolades for its component set, if it even has any.  I'm subjective as 
I've never physically downloaded nor installed it... I keep saying I will, 
but they never make it sound appealing; it's free, and that still doesn't 
make me want it.

- Original Message - 
From: Scott Barnes [EMAIL PROTECTED]
To: flexcoders@yahoogroups.com
Sent: Thursday, April 28, 2005 9:00 PM
Subject: Re: [flexcoders] Newbie: Flash vs. Flex, CPUs, Lazslo


On 4/29/05, Jim Schneider [EMAIL PROTECTED] wrote:
 1. Could someone explain (or point me to a doc/faq) that tells me why I
 would choose Flex over Flash. What can Flex do that Flash can't? Even if
 it's more difficult in Flash, perhaps it's worth it given the cost of 
 Flex.

I'll take a stab at this one.

As a Flash IDE developer for many a year, I've found that its really a
bottle neck and a slow process at times. Flash IDE takes a lot of
discipline and understanding of the concept of flash itself and you
better be armed before taking on a large project.

When developing in large projects you tend to be a one man show, as to
share resources or code amongst other developers takes a lot of
communication and patience. That alone improves why FLEX is a valid
purchase.

As for what can FLEX do FLASH can't? not much technically as FLEX is
really an alternative approach to the end goal. It does bring a lot
more to the table then FLASH IDE in terms of Rapid Development. An
example would be Remoting, any here who have used Flash Remoting in
IDE form know its more tedious to implement then FLEX. Its examples
like this that change your perspective on FLASH vs FLEX.

On top of that, FLEX handles a lot of your tasks for you, things like
initialization modals, busy cursors, history management etc are all
automated tasks within FLEX.

In terms of costs, i've seen soo many projects take months to do
what could be done in FLEX in half the time. These are also run by
some very competent FLASH developers who have years of experience and
know the language/tool off by heart. Its just cumbersome, slow and at
times very tedious.

That being said, you do a lot more control visually / debugging wise
in FLASH IDE then you currently at present have in FLEX. On top of
that your portability is much more open then at present with FLEX.

Implementing Runtime Shared Libraries in FLASH IDE is awful and
painful, just ask JessterXL all about that one, he's mastered it but
he went through a learning curve and pain to get to that point. I like
wise, i think i've got it mastered but found it took a lot of
imagination and research.

In FLEX? bah its next to easy as implementing a Tree component.

In FLASH MX 2004 Pro, implementing even a Tree component (databinding
aside) isn't a simple task and requires some extra work then compared
to FLEX.

Cost wise, you'll blow more money using FLASH IDE then you will via
FLEX for a large application.

If you are building a small RIA app that isn't as large and doesn't
require a team of developers to work on, then yes FLASH MX 2004 Pro is
the suitable resource.

 2. Speaking of cost, I read on MM's site that they recommend a typical
 deployment of a Flex app have 6 - 8 CPUs. Is this true in practice? If I
 have an app that has 50 users (would grow to perhaps 10K users) who don't
 hit the system very hard, what are CPU requirements? Are there any
 performance benchmarks that I can use as a guideline for what I would need
 initially and at what point I would need to upgrade. As a small company, 
 we
 can probably chew off $12K, $70K is another story (unless I misunderstand
 the licensing).

Not sure on server-side, i've oftend wondered that my self and while
i've read various optimization techniques and resources i'm still
skeptical of its use in terms of high volume. That being said, we
could