Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Has someone used Scala-JS in real web project but not only for plain JavaScript replacement in isolated env ?
I would like to use Scala as much as possible (I wish I could). And seems Scala-JS claims to be that lib I could use (now) or in the future.
That's why I'm interested in small working solution to look at, to bootstrap (like PlayFramework app where Scala-JS).
The solution/example that could demonstrate that Scala-JS can be used in real web-development work.
I'm asking because what I found about Scala-JS so far is hardly real usage of it.
Q: some examples / proves that It is ready to use in real project?
UPDATE (after 1 year):
There are tons of examples for TypeScript for example.. That what I mean when I said "examples" and "real web projects". And there many online trainings. And if I query in Google: "typescript github angular", it returns 172 000 pages. ScalaJS has lack of all it definitely and unfortunately.
But it has some: ' "scala-js" github angular ' - 4 980 matches. But so far most of it is "early stage of development" with "no commercial support"
That one seems promising: https://github.com/greencatsoft/scalajs-angular
I haven't seen client-side form validation specifically, yet. However, there are several projects that use Scala.js effectively, among which:
A basic setup with PlayFramework, where client-side JS is written in Scala.js
A more significant example with PlayFramework essentially demonstrating the Scala.js actors proof-of-concept
Other projects written in Scala.js but with nothing to do with Play, but that demonstrate Scala.js' power to varying degrees.
Roll, probably the most significant Scala.js project so far.
I just noticed this question, and should probably chime in -- as mentioned above, my company's product, Querki, has its UI now built entirely in Scala.js. That's about 8k SLOC of Scala, last I checked: not the biggest program in the world, but a lot more complex than most sites. I would guess that it's replacing what would have been 20-30k SLOC of JavaScript, and is really the only way the company is plausible at all.
That's beta for a small company, but very much in production, and it's been a godsend: the SJS code is vastly easier to write and maintain than the JavaScript it replaced, and much more stable in practice. Also, hooking the SJS front end up to my Akka/Play back end speeds up development enormously, and reduces bugs, since the API is strongly-typed and boilerplate-free, in end-to-end Scala.
Since folks have asked: the optimized JS code is currently about 1 Meg, and growing quite slowly now that all my infrastructure is written. (Plus about as much again for the JS libraries I use.) That's not trivial, but it's a one-time load per release; once it's cached in the browser, the UI is extremely fast, much quicker than the dynamic pages that had been there.
Oh, and since you're looking for a fully-worked example: the source code can be found on GitHub. That's open-but-restricted, since it's a commercial product, but feel free to dig around and use it for inspiration. (And feel free to request useful bits out of it: I'm gradually lifting broadly-useful bits and pieces into MIT-licensed libraries.)
I am actively building a dashboard webapp for my startup using scala.js. It is incomplete, but evolving quickly.
My initial prototype was based on angular.js, using the angulate bindings. I later replaced angular with a reactive-style mesh of scala.rx, scalatags and scalacss, which is takes advantage of the scala type system. All the logic/rendering is type safe and in one language (scala), rather than being spread across "stringly-typed" HTML, CSS and JavaScript
Although this webapp is being developed as an internal tool, it should be able to demonstrate scala.js in a real world application once it's finished.
Then
W3C uses it in banana-rf: github.com/w3c/banana-rdf
#jducoeur builds Querki : github.com/jducoeur/Querki
TypeSafe shares a very substantial template: typesafe.com/activator/template/play-scalajs-showcase
All of the above demonstrate rather advanced features & techniques.
The careful reader can learn a lot and determine for himself it ScalaJS is ready for prime time.
Lastly, this https://github.com/SemanticBeeng/play-scalajs-showcase is a derivative of the original showing how to apply event sourcing and functional domain models to move from a CRUD oriented API to a functional API.
This is an experiment and work in progress.
More recently (2016), you have sri (Scala React interface).
It is a scalajs library to build truly native cross platform (mobile (ios and android) and web) applications.
It is based on reactjs and react-native.
Use this module to build browser based applications:
libraryDependencies += "com.github.chandu0101" %%% "sri-web" % "0.6.0"
The official Scala.js homepage lists projects built with Scala.js: http://www.scala-js.org/community/
ThoughtWorks's TodoMVC application with the help of Binding.scala and Scala.js:
Project Page
DEMO
I don't know if it is a real web project because it seems unreally concise. The DEMO contains only one source file, 147 lines of code, while the ReactJS implementation of the same TodoMVC feature took 488 lines of code.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am planning to write a web application. However, I want to write both the client and server side in Scala. Should I choose Scala.js? or should I go for GWT. What are the cases where I have to choose one over the other? Also, are there any other Scala frameworks that can be used for client web programming aside from the two?
None of those two should be used.
ScalaGWT has been abandonned for more than a year.
Scala.js is experimental and requires your users to download a 16Mo library (it will improve, but it is unacceptable except for some game apps).
[edit] the library has been downsized and this statement is no longer true at this time.
Other technologies are available, but choosing one depends of the kind of app you want to write. If you plan to develop a thin client, using a templating technology (like JSP or JSF), you could consider using Play templates, Lift, Scalatra, ...
To help you consider your needs, here is a few thoughts:
You'll need widgets and stuff to design your UI and those things are typically component-oriented and event-driven. In such a case FP doesn't offer much advantage over OOP.
In a standard enterprise application, scala.js would be useful to design a clean functional library for js code. This kind of library definitely has much to offer but it won't be the core of your client-side code. Instead widgets, MVC infrastructure, and a layer for integration with the back-end will be what you'll spend most of your time working on.
GWT has been around for a long time. I consider it a mature and proven technology. You'll have to learn a few tweaks and patterns to be able to fully exploit its potential, but in my opinion, much less than what is needed to write clean and maintainable js code.
GWT doesn't require you to know js at all (although we all agree it's always best to know a bit about what happens in the browser). You won't go far with scala.js if you don't know what you're compiling to.
If you already know javascript well, it's going to be easier to directly type your scala code as if it were some kind of scala-enabled js .
It's much easier for large teams to work with GWT than with js, as you can factor you code easily, favoring code testing and reuse at the same time.
GWT is definitely object(widget/model/view/controller)-oriented and event-driven. If you have plans to design an interface in a fully functional way (for games or very specific apps), I think it will get in the way of your design.
GWT
Mature
It's a full-fledged toolkit
GWT-specific patterns and good practices are well-documented
Easy integration with a java/scala back-end
Development scales well over big teams
Best if you don't know js yet
Object-oriented, GWT goodness is there (dependency injection, MVP, Async, i18n, JSR-303 validation ...)
Will optimize and compile your code to a small js file
Scala.js
Quite new, work-in-progress
Not a toolkit, but a compiler.
Hence you'll need to be aware about js good practices, design patterns and libraries, since your scala code will be interacting with js (quite) directly
Need to write/wire a layer for integration with the back-end yourself
Much harder to handle a big team
No need to know GWT :-)
Functional programming, Scala goodness is there (trait, patterns, case classes, ...)
[edit] At the time the question was asked, required a 16 Mo library
Final advice
Do you need widgets and complex interactions betweens UI components or is it enough for you to use a templating technology ?
Use ScalaGWT at your own risk.
You could use scala.js for js library design, experimental projects, games, ... You can call the js code compiled from scala.js from your GWT app (if you get past the 16 Mo library)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I've just started learning Scala, and the first thing I'm going to implement is a tiny web application. I've been using Erlang for the last year to implement server-side software, but I've never wrote web applications before. It will be a great experience.
Are there web-frameworks for Scala except for Lift?
Don't get me wrong, Lift looks awesome. I just want to know how many frameworks there are so that I can then choose between them. It's always a good to have a choice, but I the only thing I found was Lift.
I'm very interested in Scala, but I have not used it yet, so with that caveat, the frameworks I am aware of that are not mentioned in HRJ's answer (Lift, Sweet, Slinky) are:
Scalatra, previously Step (on GitHub)
Play 2 (on GitHub)
Pinky
I wrote a blog post about this.
To summarise, some of the options are:
Lift
Sweet
Slinky
I finally found that none were suitable for me, and developed my own little "framework". (It is not open-source yet).
I like Lift ;-)
Play is my second choice for Scala-friendly web frameworks.
Wicket is my third choice.
Following is a dump of frameworks. It doesn't mean I actually used them:
Coeus. A traditional MVC web framework for Scala.
Unfiltered. A toolkit for servicing HTTP requests in Scala.
Uniscala Granite.
Gardel
Mondo
Amore. A Scala port of the Ruby web framework Sinatra
Scales XML. Flexible approach to XML handling and a simplified way of interacting with XML.
Belt. A Rack-like interface for web applications built on top of Scalaz-HTTP
Frank. Web application DSL built on top of Scalaz/Belt
MixedBits. A framework for the Scala progamming language to help build web sites
Circumflex. Unites several self-contained open source projects for application development using the Scala programming language.
Scala Webmachine. Port of Basho's webmachine in Scala, a REST-based system for building web applications
Bowler. A RESTful, multi-channel ready Scala web framework
Try Play Framework, which also support Scala.
One very interesting web framework with commercial deployment is Scalatra, inspired by Ruby's Sinatra. Here's an InfoQ article about it.
I find Unfiltered very interesting https://github.com/unfiltered/unfiltered.
It's mentioned in IttayD's list.
Here is a presentation about it http://unfiltered.lessis.me/#0
and the video http://code.technically.us/post/942531598/doug-tangren-presents-the-unfiltered-toolkit-for
Also here there is an article with more info http://code.technically.us/post/998251172/holding-the-parameter
It must be noted that there is also a considerable interest in Wicket and Scala. Wicket fits Scala suprisingly well. If you want to take advantage of the very mature Wicket project and its ecosystem (extensions) plus the concise syntax and productivity advantage of Scala, this one may be for you!
See also:
Some prosa
Presentation
Some experience with Wicket and Scala
Announcments with reference to the project for the glue code to bind Scala closures to models
Play is pretty sweet.
It is now production ready. It incorporates: a cool template framework,automatic reloading of source files upon safe, a composable action system, akka awesomeness, etc.
Its part of the Typesafe Stack.
Having used it for two projects, I can say that it works pretty smoothly and it should be something to consider next time you are looking to learn new web frameworks.
I tend to use JAX-RS using Jersey (you can write nice resource beans in Scala, Java or Groovy) to write RESTul web applications. Then I use Scalate for the rendering the views using one of the various template languages (JADE, Scaml, Ssp (Scala Server Pages), Mustache, etc.).
There's a new web framework, called Scala Web Pages. From the site:
Target Audience
The Scala Pages web framework is likely to appeal to web programmers who come from a Java background and want to program web applications in Scala. The emphasis is on OOP rather than functional programming.
Characteristics And Features
Adheres to model-view-controller paradigm
Text-based template engine
Simple syntax: $variable and <?scp-instruction?>
Encoding/content detection, able to handle international text encodings
Snippets instead of custom tags
URL Rewriting
Prikrutil, I think we're on the same boat. I also come to Scala from Erlang. I like Nitrogen a lot so I decided to created a Scala web framework inspired by it.
Take a look at Xitrum. Its doc is quite extensive. From README:
Xitrum is an async and clustered Scala web framework and web server on top of Netty and Hazelcast:
It fills the gap between Scalatra and Lift: more powerful than Scalatra and easier to use than Lift. You can easily create both RESTful APIs and postbacks. Xitrum is controller-first like Scalatra, not view-first like Lift.
Annotation is used for URL routes, in the spirit of JAX-RS. You don't have to declare all routes in a single place.
Typesafe, in the spirit of Scala.
Async, in the spirit of Netty.
Sessions can be stored in cookies or clustered Hazelcast.
jQuery Validation is integrated for browser side and server side validation.
i18n using GNU gettext, which means unlike most other solutions, both singular and plural forms are supported.
Conditional GET using ETag.
Hazelcast also gives:
In-process and clustered cache, you don't need separate cache servers.
In-process and clustered Comet, you can scale Comet to multiple web servers.
Follow the tutorial for a quick start.
There's also Pinky, which used to be on bitbucket but got transfered to github.
By the way, github is a great place to search for Scala projects, as there's a lot being put there.
I'd like to add my own efforts to this list. You can find out more information here:
brzy framework
It's in early development and I'm still working on it aggressively. It includes features like:
A focus on simplicity and extensibility.
Integrated build tool.
Modular design; some initial modules includes support for scalate, email, jms, jpa, squeryl, cassandra, cron services and more.
Simple RESTful controllers and actions.
Any and all feedback is much appreciated.
UPDATE: 2011-09-078, I just posted a major update to version 0.9.1. There's more info at http://brzy.org which includes a screencast.
Both Sweet and Slinky seem to be unmaintanted for about a year. Sweet Maven repo sweetsoftwaredesign.com is dead so there's even no way to download dependencies.
Note: Spiffy is outdated.
<plug>
Spiffy:
is written in Scala
uses the fantastic Akka library and actors to scale
uses servlet API 3.0 for asynchronous request handling
is modular (replacing components is straight forward)
uses DSLs to cut down on code where you don't want it
supports Scalate and Freemarker for templating
Spiffy is a web framework using Scala, Akka (a Scala actor implementation), and the Java Servlet 3.0 API. It makes use of the the async interface and aims to provide a massively parallel and scalable environment for web applications. Spiffy's various components are all based on the idea that they need to be independent minimalistic modules that do small amounts of work very quickly and hand off the request to the next component in the pipeline. After the last component is done processing the request it signals the servlet container by "completing" the request and sending it back to the client.
https://github.com/mardambey/spiffy
</plug>
You could also try Context. It was designed to be a Java-framework but I have successfully used it with Scala also without difficulties. It is a component based framework and has similar properties as Lift or Tapestry.
I have stumbled upon your question a few weeks back, but since then also learned about Circumflex. This is a nice, minimal framework that is therefore easy to learn, and it has pretty good documentation available as well.
Beside it's minimal-ness, it also claims to work well with other libraries and lets you use your own implementation of things when you need it.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
My company is planning on developing a brand new web front-end application.
Some background:
It must "sizzle" i.e. a nice marketable look and feel.
Our development team has no Java experience, with limited experience in Silverlight, Javascript, JQuery or CSS.
Time to market is a factor.
We need to stream large amounts of data from an Oracle database.
It must support 500 - 1000 concurrent users
It will be hosted internally behind a firewall.
We need mapping (geo-spatial) capabilities.
Someone has recommended using GWT instead of Silverlight or Traditional technologies(Javascript, jquery, CSS etc.).
I am not sure if this is the right way to go? A lot of the GWT news is from 2007/2008. It makes me think that this technology is old and maybe dying.
If you had a choice would you choose GWT?
unfortunately two of your statements are mutually exclusive in this context:
Our development team has no Java experience
Time to market is a factor
I'm a Java programmer who has picked up GWT over the last year or so. It's immensely effective being able to write direct to the browser using a compiled language & mature development tools. I can fly through web-development faster than ever before (using ASP, JSP, ExtJS ...).
But, as the other commenters have said: if you've no Java experience you're going to find it a real challenge picking up both technologies (Java & GWT) in a short time. If you do manage to make it to market in a reasonable time I could only imagine the code base would be in very poor condition (since you'd be learning as you go) - which would be a very poor foundation for your organisation's shiny new venture.
There again, you don't have a 'lot' of skills in the other related skills you listed either.
I suspect there's a more effective solution. As some wise old goat project manager said:
I have three variables to delivering your project: time, cost and quality. Pick any two
In your situation, if the organisation wants a quality product in a short time, it's the cost factor that must compensate - your organisation should buy in some interim GWT expertise to give you a sound software architecture and to mentor your team for the next few months. After that you'll be ready to take the reigns, inheriting a quality codebase by 'standing on the shoulders of giants'.
As others have said, GWT definitely is not a dying project. Quite the contrary actually as there are now more than 20 regular contributors from within Google (versus a semi-dozen back in 2008). Wave (despite being discontinued as a Google service, it's still alive as an Apache Foundation project), Orkut, AdWords, Google Moderator and the new (still beta) Google Groups are made with GWT; and parts of Google Buzz and a few other projects at Google are built with it too.
Now as to your choice:
Silverlight is a dying technology. Microsoft made it clear that it now invests in "HTML5": http://www.zdnet.com/blog/microsoft/microsoft-our-strategy-with-silverlight-has-shifted/7834
GWT is mostly a client-side toolkit, but it comes with "high productivity" tools for client-server communications (GWT-RPC and RequestFactory for end-to-end protocols, AutoBeans for easy JSON serialization). With UiBinder, you can easily put to use your web designer skills.
if you're comfortable with JS, then go for it, but then you'd have to choose the "right toolkit" (jQuery? Google Closure?). Otherwise (which seems to be the case), it really depends how much "ajaxy" you need/want to be. I'm a strong believer in "one-page apps", but YMMV, or you can have specific constraints that rule it out. In any case, you'd have to choose a server-side technology.
So, depending on your needs/wants and skills, I'd choose GWT or "some JS toolkit". In any case, you'll have full control over the look and feel (unless you choose one of the bloated players: ExtJS/ExtGWT, SmartGWT or similar; you'll probably have a shorter time-to-market with these, but you'll pay it later, in terms of performance, integration with other toolkits, and look-and-feel).
In the light of what you're saying about your skills, I would definitely recommend GWT (despite your lack of experience with Java); because lack of experience with JavaScript is far worse than lack of experience with Java (you're talking about a "large application", so it's really important to start building things right and/or have tools to help refactoring, which you'll have with Java).
#ianmayo replied while I was writing the above, and I can only second what he said!
GWT is definitely not old or dying! A lot of Google's own applications are developed using GWT. You can download the GBST case study and learn how the global financial company uses GWT to improve productivity and create a rich user experience. You have to know that when you use GWT you automatically use javascript, html, etc. You create a your gwt application in java, but when you compile it gwt creates a folder with html files, javascript code, css, etc...
I definitely recommend it!
In order not to mislead readers with above seemingly unanimous answers, keep objective view in respected stackoverflow, following review expressed exact experiences I had with using GWT. Whether GWT is dying depends on how many new apps will adopt it,Google trend can tell (gwt trend).
Excerpt from https://softwareengineering.stackexchange.com/questions/38441/when-not-to-use-google-web-toolkit
>
I am both good and bad to answer this question - good, in that I've actually used it before, and bad, in that I was quite experienced with HTML/CSS/JavaScript prior to working with GWT. This left me maddened by using GWT in a way that other Java developers who don't really know DHTML may not have been.
GWT does what it says - it abstracts JavaScript and to some degree HTML into Java. To many developers, this sounds brilliant. However, we know, as Jeff Atwood puts it, all abstractions are failed abstractions (worth a read if considering GWT). With GWT, this specifically introduces the following problems:
Using HTML in GWT sucks.
As I said it, to some degree, even abstracts away HTML. It sounds good to a Java developer. But it's not. HTML is a document markup format. If you wanted to create Java objects to define a document, you would not use document markup elements. It is maddeningly verbose. It is also not controlled enough. In HTML there is essentially one way to write
<p>Hello how are <b>you</b>?</p>
In GWT, you have 3 child nodes (text, B, text) attached to a P node. You can either create the P first, or create the child nodes first. One of the child nodes might be the return result of a function. After a few months of development with many developers, trying to decipher what your HTML document looks like by tracing your GWT code is a headache-inducing process.
In the end, the team decided that maybe using HTMLPanel for all HTML was the right way to go. Now, you've lost many of GWT's advantages of having elements readily available to Java code to bind easily for data.
Using CSS in GWT sucks.
By attachment to HTML abstraction, this means that the way you have to use CSS is also different. It might have improved since I last used GWT (about 9 months ago), but at the time, CSS support was a mess. Because of the way GWT makes you create HTML, you often have levels of nodes that you didn't know were injected (any CSS dev knows how this can dramatically affect rendering). There were too many ways to embed or link CSS, resulting in a confusing mess of namespaces. On top of that you had the sprite support, which again sounds nice, but actually mutated your CSS and we had problems with it writing properties which we then had to explicitly overwrite later, or in some cases, thwarted our attempts to match our hand-coded CSS and having to just redesign it in ways that GWT didn't screw it up.
Union of problems, intersection of benefits
Any languages is going to have it's own set of problems and benefits. Whether you use it is a weighted formula based on those. When you have an abstraction, what you get is a union of all the problems, and an intersection of the benefits. JavaScript has it's problems, and is commonly derided among server-side engineers, but it also has quite a few features that are helpful for rapid web development. Think closures, syntax shorthand, ad-hoc objects, all of the stuff done by Jquery (like DOM querying by CSS selector). Now forget about using it in GWT!
Separation of concerns
We all know that as the size of a project grows, having good separation of concerns is critical. One of the most important is the separation between display and processing. GWT made this really hard. Probably not impossible, but the team I was on never came up with a good solution, and even when we thought we had, we always had one leaking into the other.
Desktop != Web
As #Berin Loritsch posted in the comments, the model or mindset GWT is built for is living applications, where a program has a living display tightly coupled with a processing engine. This sounds good because that's what so many feel the web is lacking. But there are two problems: A) The web is built on HTTP and this is inherently different. As I mentioned above, the technologies built on HTTP - HTML, CSS, even resource-loading and caching (images, etc.), have been built for that platform. B) Java developers who have been working on the web do not easily switch to this desktop-application mindset. Architecture in this world is an entirely different discipline. Flex developers would probably be more suited to GWT than Java web developers.
In conclusion...
GWT is capable of producing quick-and-dirty AJAX applications quite easily using just Java. If quick-and-dirty doesn't sound like what you want, don't use it. The company I was working for was a company that cared a lot about the end product, and it's sense of polish, both visual and interactive, to the user. For us front-end developers, this meant that we needed to control HTML, CSS, and JavaScript in ways that made using GWT like trying to play the piano with boxing gloves on
First of all , GWT is not dying technology, its usage increases, and its latest version is 2.2. I am using GWT for 2 years, since version 1.6. Its improvements since them is quite amazing.
Since GWT is client side technology, it does have only positive effects of your application scaliblity feature. Because server side web technologies such as jsf, struts, wicket are server resource consumers, but gwt does not need any server resource to render user interface..
But there is problem for your team. Because your team has no java experience, it would be quite difficult to adapt yourself two new technologies java and gwt.. If you have time to learn , I would strongly suggest GWT.
It takes approx 1 year to become proficient in GWT. Using GWT pays off if you develop an application as sophisticated as MicrosoftOffice or PhotoShop. It makes no sense to use GWT for small and relatively simple apps, IMHO. GWT is a time killing framework indeed, and you have to have very strong reasons to use it. I think that 99% of web apps don't need GWT.
GWT is not dying framework, but time killing framework. It has security issue. You can do easily CSRF(Cross site request forgery) request to the GWT applications. Also Java and Javascript are totally different languages, you can't translate easily. For your productivity avoid GWT.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
From the following list of frameworks, which one would you use to develop a rich web application and why would you choose it over the others?
Sproutcore
GWT
ExtJS
GXT
SmartGWT
Dojo / Dijit
Flex
Capuccino
Grails
I'm personally tired of browser inconsistencies. If someone else has solved the problem, I'd rather not do it again. That's why I'm getting more interested in front ends like cappuccino and qooxdoo. They are a zero-HTML zero-CSS solution.
These are based on my personal experiences using the frameworks you have mentioned. So yes, it is a bit biased. So as others have said over and over again, define your requirements and which one do you think fits your requirement based on what people have suggested here.
GWT is too verbose eventhough I found many Java developers love GWT because you can unit test it and it's all in Java. But I personally don't like it because it is far from being simple. There are times when I feel I can tweak a little bit with Javascript, but with GWT I am enforced to do it with several lines of Java code.
GXT is too far from GWT these days and you will find it difficult to do things as GXT has its own way of doing things which is way too different from GWT. When complex requirement come up, in the end you are going to go back doing plain GWT. And oh, their technical support is not that good either as I had several bad experiences when asking few questions to them.
Ext-JS is good for simple stuff and the look and feel is really slick. But when things gets more complex, you are going to fight you're way through. Eventhough I have dealt with the GXT tech support, I haven't dealt with the ExtJS tech support since they have different people eventhough it's in one company, so I can't say much.
Flex is nice, really nice. But again it is good for simple stuff. Once things gets more complicated you are going to write lots of actionscript, which is less enjoyable. There are many things that is available out of the box which may be to difficult if you have to code it in Javascript, like multimedia support. And oh, if you are writing for a public website you must consider that not too many user has flash plugin on their browser.
Grails, I'm not sure how you would implement RIA apps with Grails since Grails is just another MVC framework which you need to add your own RIA framework on top of it such as the ones that you have mentioned.
This is strictly a matter of opinion. You will not get any definitive answers from anyone, since anyone that answers will have one or another that they personally prefer.
Try each one for long enough to decide which one is best for your (or your team's) purposes.
That being said, I prefer GWT. Others will invariably disagree with me.
Reasons that I like GWT:
You can share (some) client- and server-side code (as long as your server is written in Java)
GWT makes a lot of advanced performance features really easy (e.g., deferred JS loading, image spriting, CSS obfuscation)
A focus on one-page apps, with third-party support for Places (using the gwt-presenter library)
It's just as easy to add GWT to an existing web page as it is to create a full one-page GWT app
UiBinder allows you to write your UI using a declarative HTML-like syntax; you're not stuck writing Swing-like UI if you don't want to
Browser incompatibilities are (mostly) taken care of by GWT -- you just write Java code, and GWT compiles it to work on every browser
Things that may make GWT not right for you:
If your server is already written in something besides Java, you will still be able to write your UI in GWT, but you'll lose out on some nice features
Compilation time using GWT is a non-trivial cost -- Development Mode mitigates this a lot, but it's still an issue sometimes
As others have mentioned, GWT can be considered "verbose" compared to simple JavaScript libraries like jQuery or ExtJS
Ext GWT has worked well for my project. The premium support has been good.
However the project is for internal use which has allowed deployment to be restricted to one browser on one OS, and no effort has been made to change the default appearance or behaviour of Ext GWT.
Developing entirely within Java is a key benefit as it helps to keep the project manageable as features are added.
I am currently working on a grail/flex hybrid app that is working a lot better than I expected. I have looked at GWT but there were not a lot of books about it at the time and it seemed to stress the leveraging of Swing-like programming techniques which I have never liked. I agree with the comment about trying them all out. Run hello app they all have and measure how hard or easy it is to modify. Also tool (IDEs, Maven, CI...etc) support can be a big factor as well in terms of being immediately productive.
We are using Grails+ExtJS here. Since we try to make an idiomatic ExtJS application, Grails is not fully utilized, though it still makes sense to use Grails instead of, say, JSP, for the server-side part.
Why ExtJS: Because it's a very rich toolkit for GUI-like web applications. Our job is to replace an old Motif GUI, so this is exactly what we need.
Why Grails: Because it gets the job done easily and quickly. For the communication with the ExtJS part, we need a lot of JSON, and in Grails it's like that:
import foo.bar.FooBar
class FooBarController {
def viewFooBars = {
def list = FooBar.getList(session.userId, params.foo, params.bar)
def result = [resultset: list] as JSON
response.setHeader('Content-disposition', 'filename="json"')
response.contentType = "text/json";
render result
}
}
And that's even two or three lines more than necessary...
Unfortunately the answer will be opinionated, GWT in it's purest form is not an eye-candy. That being said, ExtJs GXT is super hunky dory. One of the major issues I face with evolving frameworks is that they are not absolutely defect free, If I remember correctly, GWT 2.0 was shipped out with missing CSS styles for some of the new layouts. I am trying to trouble shoot an issue in ExtJs/GXT since last 5 days :(, frameworks obfuscate a lot of things. I will go with any framework that is absolutely robust and gives appropriate error messages. I haven't worked with others though.
I'd recommend Dojo.
In addition to the massive infrastructure it provides, Dojo 1.6 is also the first (and only) popular JavaScript Library that can be successfully used with the Closure Compiler's Advanced mode, with all the size, performance and obfuscation benefits attached to it -- other than Google's own Closure Library, that is.
http://dojo-toolkit.33424.n3.nabble.com/file/n2636749/Using_the_Dojo_Toolkit_with_the_Closure_Compiler.pdf?by-user=t
In other words, a program using Dojo can be 100% obfuscated -- even the library itself.
Compiled code has exactly the same behavior as plain-text code, except that it is much smaller (average 25% over minifiers), runs much faster (especially on mobile devices), and almost impossible to reverse-engineer, even after passing through a beautifier, because the entire code base (including the library) is obfuscated.
Code that is only "minified" (e.g. YUI compressor, Uglify) can be easily reverse-engineered after passing through a beautifier.
ExtJs is great for creating complex web applications. The API provides anything you can imagine in a webapp and its really easy to extend any component after some time.
You can plug it to any backend (we use django or php) and reuse or extend any component in several different applications.
You'll need severals months to feel comfortable with it. IMHO.
That said, the lib is sometimes a bit too slow for simples uis like a website (then you can use ExtCore). But when it comes to webapps this is not an issue.
Im not a java guy so GWT was not an option for me :/
hope this helps
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I've just started learning Scala, and the first thing I'm going to implement is a tiny web application. I've been using Erlang for the last year to implement server-side software, but I've never wrote web applications before. It will be a great experience.
Are there web-frameworks for Scala except for Lift?
Don't get me wrong, Lift looks awesome. I just want to know how many frameworks there are so that I can then choose between them. It's always a good to have a choice, but I the only thing I found was Lift.
I'm very interested in Scala, but I have not used it yet, so with that caveat, the frameworks I am aware of that are not mentioned in HRJ's answer (Lift, Sweet, Slinky) are:
Scalatra, previously Step (on GitHub)
Play 2 (on GitHub)
Pinky
I wrote a blog post about this.
To summarise, some of the options are:
Lift
Sweet
Slinky
I finally found that none were suitable for me, and developed my own little "framework". (It is not open-source yet).
I like Lift ;-)
Play is my second choice for Scala-friendly web frameworks.
Wicket is my third choice.
Following is a dump of frameworks. It doesn't mean I actually used them:
Coeus. A traditional MVC web framework for Scala.
Unfiltered. A toolkit for servicing HTTP requests in Scala.
Uniscala Granite.
Gardel
Mondo
Amore. A Scala port of the Ruby web framework Sinatra
Scales XML. Flexible approach to XML handling and a simplified way of interacting with XML.
Belt. A Rack-like interface for web applications built on top of Scalaz-HTTP
Frank. Web application DSL built on top of Scalaz/Belt
MixedBits. A framework for the Scala progamming language to help build web sites
Circumflex. Unites several self-contained open source projects for application development using the Scala programming language.
Scala Webmachine. Port of Basho's webmachine in Scala, a REST-based system for building web applications
Bowler. A RESTful, multi-channel ready Scala web framework
Try Play Framework, which also support Scala.
One very interesting web framework with commercial deployment is Scalatra, inspired by Ruby's Sinatra. Here's an InfoQ article about it.
I find Unfiltered very interesting https://github.com/unfiltered/unfiltered.
It's mentioned in IttayD's list.
Here is a presentation about it http://unfiltered.lessis.me/#0
and the video http://code.technically.us/post/942531598/doug-tangren-presents-the-unfiltered-toolkit-for
Also here there is an article with more info http://code.technically.us/post/998251172/holding-the-parameter
It must be noted that there is also a considerable interest in Wicket and Scala. Wicket fits Scala suprisingly well. If you want to take advantage of the very mature Wicket project and its ecosystem (extensions) plus the concise syntax and productivity advantage of Scala, this one may be for you!
See also:
Some prosa
Presentation
Some experience with Wicket and Scala
Announcments with reference to the project for the glue code to bind Scala closures to models
Play is pretty sweet.
It is now production ready. It incorporates: a cool template framework,automatic reloading of source files upon safe, a composable action system, akka awesomeness, etc.
Its part of the Typesafe Stack.
Having used it for two projects, I can say that it works pretty smoothly and it should be something to consider next time you are looking to learn new web frameworks.
I tend to use JAX-RS using Jersey (you can write nice resource beans in Scala, Java or Groovy) to write RESTul web applications. Then I use Scalate for the rendering the views using one of the various template languages (JADE, Scaml, Ssp (Scala Server Pages), Mustache, etc.).
There's a new web framework, called Scala Web Pages. From the site:
Target Audience
The Scala Pages web framework is likely to appeal to web programmers who come from a Java background and want to program web applications in Scala. The emphasis is on OOP rather than functional programming.
Characteristics And Features
Adheres to model-view-controller paradigm
Text-based template engine
Simple syntax: $variable and <?scp-instruction?>
Encoding/content detection, able to handle international text encodings
Snippets instead of custom tags
URL Rewriting
Prikrutil, I think we're on the same boat. I also come to Scala from Erlang. I like Nitrogen a lot so I decided to created a Scala web framework inspired by it.
Take a look at Xitrum. Its doc is quite extensive. From README:
Xitrum is an async and clustered Scala web framework and web server on top of Netty and Hazelcast:
It fills the gap between Scalatra and Lift: more powerful than Scalatra and easier to use than Lift. You can easily create both RESTful APIs and postbacks. Xitrum is controller-first like Scalatra, not view-first like Lift.
Annotation is used for URL routes, in the spirit of JAX-RS. You don't have to declare all routes in a single place.
Typesafe, in the spirit of Scala.
Async, in the spirit of Netty.
Sessions can be stored in cookies or clustered Hazelcast.
jQuery Validation is integrated for browser side and server side validation.
i18n using GNU gettext, which means unlike most other solutions, both singular and plural forms are supported.
Conditional GET using ETag.
Hazelcast also gives:
In-process and clustered cache, you don't need separate cache servers.
In-process and clustered Comet, you can scale Comet to multiple web servers.
Follow the tutorial for a quick start.
There's also Pinky, which used to be on bitbucket but got transfered to github.
By the way, github is a great place to search for Scala projects, as there's a lot being put there.
I'd like to add my own efforts to this list. You can find out more information here:
brzy framework
It's in early development and I'm still working on it aggressively. It includes features like:
A focus on simplicity and extensibility.
Integrated build tool.
Modular design; some initial modules includes support for scalate, email, jms, jpa, squeryl, cassandra, cron services and more.
Simple RESTful controllers and actions.
Any and all feedback is much appreciated.
UPDATE: 2011-09-078, I just posted a major update to version 0.9.1. There's more info at http://brzy.org which includes a screencast.
Both Sweet and Slinky seem to be unmaintanted for about a year. Sweet Maven repo sweetsoftwaredesign.com is dead so there's even no way to download dependencies.
Note: Spiffy is outdated.
<plug>
Spiffy:
is written in Scala
uses the fantastic Akka library and actors to scale
uses servlet API 3.0 for asynchronous request handling
is modular (replacing components is straight forward)
uses DSLs to cut down on code where you don't want it
supports Scalate and Freemarker for templating
Spiffy is a web framework using Scala, Akka (a Scala actor implementation), and the Java Servlet 3.0 API. It makes use of the the async interface and aims to provide a massively parallel and scalable environment for web applications. Spiffy's various components are all based on the idea that they need to be independent minimalistic modules that do small amounts of work very quickly and hand off the request to the next component in the pipeline. After the last component is done processing the request it signals the servlet container by "completing" the request and sending it back to the client.
https://github.com/mardambey/spiffy
</plug>
You could also try Context. It was designed to be a Java-framework but I have successfully used it with Scala also without difficulties. It is a component based framework and has similar properties as Lift or Tapestry.
I have stumbled upon your question a few weeks back, but since then also learned about Circumflex. This is a nice, minimal framework that is therefore easy to learn, and it has pretty good documentation available as well.
Beside it's minimal-ness, it also claims to work well with other libraries and lets you use your own implementation of things when you need it.