Architecturally SpiffyUI is awesome. But no momentum compared to Vaadin. What is the roadmap for SpiffyUI?

64 views
Skip to first unread message

Rafiq Ahamed

unread,
Aug 11, 2013, 4:35:08 PM8/11/13
to spif...@googlegroups.com
Dear Zack,
    I have been a heavy user of GWT for the past 4 years in many projects. I always found GWT-RPC is a pain and to me, SpiffyUI is a great framework that matches my server agnostic RESTFUL thoughts. In fact, more radically, SpiffyUI can be used with Json style schema less NoSQL databases such as Apache CouchDB or better Apache Solr. Unfortunately, I am seeing a server side  framework like Vaadin is gaining momentum. Nothing against Vaadin but it is once again a painful server side framework. I hope this great concept called SpiffyUI does not die. We are not seeing major updates in SpiffyUI at all for the past 1 year. Any thoughts on Roadmap for Spiffy UI please since people like me are seriously thinking to move to Spiffy UI in all our projects.

Zack Grossbart

unread,
Aug 11, 2013, 7:47:10 PM8/11/13
to spif...@googlegroups.com
Hello Rafiq,

Thank you for your interest in Spiffy UI.

The short term roadmap for Spiffy UI is to release version 1.2 on August
15th. This new version will have upgraded libraries, a lot of bug fixes,
and some very comprehensive support for OAuth 2.0.

The longer term roadmap is a bit looser than that. We have a lot of
projects based on Spiffy UI and we'll continue to support and fix it for a
while. However, we're pretty happy with the feature set of Spiffy UI and we
don't have plans to add more features. We're always happy to take feature
requests, but we're trying to make sure the framework stays pretty light.

Please let us know if you have any other questions about Spiffy UI. We'd
love to talk more about the future, hear any feature requests you have, and
know more about the projects you're considering.

Thanks,
Zack
--
You received this message because you are subscribed to the Google Groups
"Spiffy UI" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to spiffy-ui+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Rafiq Ahamed

unread,
Aug 12, 2013, 2:28:00 AM8/12/13
to spif...@googlegroups.com
This is excellent news. Great to know that SpiffyUI will continue to grow. Couple of more questions.

1. Any thoughts on DojoToolkit being integrated into SpiffyUI?
2. And also, one of the weaknesses of the Thick architectures like SpiffUI over thin ones (Vaadin) is about security. The Thin guys claim that the total business logic coming into client side will make the business logic unprotected. We know GWT obfuscates it and we also we can override the default obfuscation with different obfuscation. Any thoughts in this particular security issue?


You received this message because you are subscribed to a topic in the Google Groups "Spiffy UI" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/spiffy-ui/TPVNvGKaMTo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to spiffy-ui+...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.





--
A. Rafiq Ahamed, 
Founder, CEO & Systems Architect,
Ethical Intelligent Technologies. 

Zack Grossbart

unread,
Aug 12, 2013, 7:21:14 AM8/12/13
to spif...@googlegroups.com
Hi Rafiq,

Spiffy UI is designed to be a light weight framework on the page.  That makes it integrate well with just about every other JavaScript framework out there.  We've never tried integrating it with the DojoToolkit, but we've done enough others to be pretty confident it will work.

Security is something we've spent a lot of time working through with Spiffy UI.  We use Spiffy UI to create high security applications for governments, large financial institutions, and many other Fortune 500 companies.  When we deploy Spiffy UI application we make the entire client code available anonymously.  This does make it possible for an attacker to decompile our code and figure out what it's doing, but we think that's a good thing.

Making our code available means we have to think through all areas of our security model.  Securing our application at the REST API layer makes it easy to determine where the security threats are.

Cheers,
Zack

Rafiq Ahamed

unread,
Aug 12, 2013, 9:32:48 AM8/12/13
to spif...@googlegroups.com
Hi Zack,
    First of all, it is great to see your email responses so quickly. Great to know that Spiffy UI is being used for highly secure applications but I am really not understanding how "making entire client code available enhances security". My biggest worry is that, after going in this model, our entire code is stolen in a flash by decompiling. How do you prevent that? Can you please shed some light on this.

Zack Grossbart

unread,
Aug 12, 2013, 9:55:47 AM8/12/13
to spif...@googlegroups.com
Hi Rafiq,

Web applications are separated into two fundamental parts:  the client side and the server side.  Whatever language you write the client side in you end up with JavaScript in the browser.  There's really no way to make it impossible to download your client side code and that's OK.

If your security depends on an attacker not know how things work then you only have security through obscurity.  When an attacker does find out how things work, and they always do, then your security is gone.  Making the client code available to attackers forces you to keep that code secure even if they can see it.  Thinking about security at that level makes your entire application more secure.

Having said all of that, this is really a philosophical debate.  I think you get more security by being more open about the implementation and letting people find the holes.  This is a big win we get by making Spiffy UI open source.  There is a counter argument that you shouldn't provide any details that could help an attacker.  I think that approach is short sighted, but there are other opinions.

Wikipedia has a pretty good starting article about this:  http://en.wikipedia.org/wiki/Security_through_obscurity

I hope that helps,
Zack

Rafiq Ahamed

unread,
Aug 12, 2013, 12:24:04 PM8/12/13
to spif...@googlegroups.com
Hmmm... I agree that Security through obscurity should not be the only means of security. It always helps by keeping "Security through obscurity" as a first step but making sure we add all the other security features properly. In this context, do you think GWT obfuscation helps? I saw in the GWT in Action book that we can have our own algorithm of generating obfuscated code. Do you think that helps? Do you think we can add that to Spiffy UI roadmap?

Zack Grossbart

unread,
Aug 12, 2013, 12:35:54 PM8/12/13
to spif...@googlegroups.com
Spiffy UI works well with any form of obfuscation you can use with GWT since it's just a GWT module.  If you're worried about sharing your client code I'd suggest you run the GWT compiler in obfuscated mode (I think this is the default with the Spiffy UI Maven build) and require SSL when running your application.

 -Zack

Rafiq Ahamed

unread,
Aug 13, 2013, 1:20:57 PM8/13/13
to spif...@googlegroups.com
Zack - Just wanted to escalate to you the response that I got from Google (via GWT contributors group) regarding integrating SpffyUI into GWT. I think you guys should start talking to them often and also I wish you be part of GWT Steering Committee.

    Brian Slesinsky <skyb...@google.com> Aug 12 04:29PM -0700  

    It seems like a nice project, but integrating it into GWT will slow down
    both the GWT developers and the SpiffyUI developers a lot. There would have
    to be some pretty compelling reasons to do that. Otherwise, better to let
    them keep doing what they're doing, and let them ask for specific changes
    to GWT if there is something they need that can't be accomplished without
    our help.

     

Zack Grossbart

unread,
Aug 13, 2013, 1:45:36 PM8/13/13
to spif...@googlegroups.com
Hi Rafiq,

Thanks for reaching out to them, but I agree with the GWT team.  Spiffy UI sits on top of GWT and in many ways it run counter to a lot of the GWT philosophy.  For example, we are committed to doing layout in CSS where GWT provides a lot of layout widgets in Java.

Brian from the GWT team is probably right that we should just keep the frameworks separate.

Thanks,
Zack

Rafiq Ahamed

unread,
Aug 13, 2013, 1:57:57 PM8/13/13
to spif...@googlegroups.com
Yes agreed. But do "ask for specific changes to GWT if there is something you guys need that can't be accomplished without
GWT Team's
 help
". Thanks.
Reply all
Reply to author
Forward
0 new messages