Related
Inspired by John Papa's video at Pluralsight, I started learning SPA. It appears pretty interesting. However, before I fully jump in, I'd like to clarify some of my questions.
From what I learnt, SPA is a lean server, fat client app. I think this should work well for small apps like what John Para demonstrated. Does it scale? How big it can be? Anybody has experience with this?
In SPA, you seem to code all the business logic in JavaScript. Is this a good idea at all? How do you hide the business "secret"?
With my background primarily in C#/WPF/.NET, moving to JavaScript seems to be very difficult (well, I learnt a little JavaScript more than 10 years ago - I hated it and never touched it again). With my limited knowledge, I ran into several problems. Debugging JavaScript seems to be a nightmare to me. The highly praised component Breezejs seems to be still in its early stage (e.g. it doesn't support UOW, doesn't support CascadeDelete, doesn't support enums). So, I'm wondering this is good time to jump in?
Directly to your questions:
Since the server logic is thin you can use some kind of cloud services and they scale pretty good. The most of the logic will be handled by the browsers of your users.
You should be careful if you depend on client. HTTP protocol can be easily manipulated. Don't forget that you should always do the validation logic both on client and server side! Also the "hidden" validation and other "secret" logic should be located only on the server.
Debugging JavaScript isn't so bad at all. You can use the built-in tools (Inspect element in Chrome and FireBug in Firefox, etc.) Also there are a lot of useful third party tools that will help you with the debugging.
If you start a new project just for your own use then I advice you to try the SPA approach. If you are writing production code you should become an expert in this area and then try to use these technologies.
Regarding UoW, take a look at the TempHire sample. It demonstrates using the UoW pattern on the client as well as the server.
https://github.com/IdeaBlade/Breeze/tree/master/Samples/TempHire
I believe SPA's provide a better framework for Business Intensive Applications as well as simpler application workflows such as that of Facebook. I have worked with Multi Page Applications for banking application with complex workflows and it get daunting to handle every thing and still keep up the application performance.
But I do think Knockout Alone wont be able to handle large applications as it is to connected in nature. I would recommend something like Backbone Marionete or Angular for that venture.
I am building a framework for large scale SPA development for the opensource community so I do believe it is the right direction.
Interested parties can go to my demo page at http:\saqibshakil.github.io I have demonstrated some of my work there.
i have been looking into it for months. My conclusion is to use Knockout with a light path.js or sammy.js for your url. I use json with a standard Visual Studio MVC ( which can return Json) as the backend.
I am still not done with the project but so far so good. It's lightning fast, elequent and lightweight.
Stay away from the frameworks. Get a look at the standard libraries: how they are written; You can learn a lot of JavaScript that way. Finally debug with chrome or explorer developer tools.
Good luck
I just recently got introduced to MV* frameworks and have taken a chance to try out Ember.js with the TodoMVC app tutorial they have on their site.
I was considering using Ember for one of my upcoming projects (a Ruby on Rails CRUD app, similar to Twitter in some of the functionality), but I'm still a bit confused and before I take a final decision I would love it if somebody could clear the following concerns:
Is it a good idea to use such an advanced framework as Ember for a medium-sized multi-page CRUD app? Will it improve development time and maintenance compared to an interactivity layer built with jQuery's DOM manipulation and AJAX capabilities? Or is using Ember (and the like) only good when developing complex single-page apps (e.g.: Grooveshark)?
Considering the app will be developed using Rails, and assuming Ember will be used, is it going to be possible to offer a fallback with basic functionality for browsers with JavaScript disabled and/or for search engine crawlers? Will it require code duplication or other dirty tricks? Do you know of any technique that can be used to achieve it?
Will it be possible to adapt the website for mobile browsing (using only CSS) with valid results, or will the overhead imposed by running Ember on the phone make it hard for the device to render the website in a way that keeps it responsive?
We're in the middle of a pretty big Ember project right now, so here are my thoughts on your questions.
We've found Ember to be really productive for creating rich UIs for our single page app, but I don't know that it's going to be that much more helpful if you're creating an app designed for traditional multi-page (viewing pages, submitting forms, etc) layout.
I think this is the clincher - Ember is completely JS-based, so if you need to support browsers without JS, you'd basically have to write a parallel application. If this is a hard requirement for your app, I think Ember (or any MV* JS framework) would be out of the question
We've had very few performance issues on mobile - our site is fully responsive and renders on everything from Blackberries to the latest Chrome on desktop with good performance.
#Scott Rankin, has addressed most of the concerns with going with the Pure Ember approach. I'll add one quick way to make this decision.
Go with Ember/MVVM if the application is behind a login. Then you don't have to consider search engines, as the content is generally private and not supposed to be indexed.
For SEO you have to build atleast part of your content such that it is indexable. A good example of this is the Discourse application. They use Ember but also send down some generated html along with the app html slugs, so that search engines can index them. You can read about their approach here.
We have a different approach which can be seen as a fall back: We pre-render a static version of each page in the application (daily scheduled task). This static version is stored on the server as HTML file. Whenever we sniff as spider/ robot user agent, we deliver that version.
I have come accross an sample application with dojo 1.5, but it's not really what I want to achieve : it is not modular at all. I want to make use of the amd, and various design patterns (like MVC) to have a very organize application. Unfortunately, the dojo community and "example" are not quite visible or present (compare to Jquery). There's a lot of cool tutorials on various implementation of specific dojo features, but none that's explain the very basic on how to create a simple (but at the same time, complex) squeleton for a dojo project. I came across the dojo boilerplate project on github, and tried to start from there, but I find it really hard (as a beginner) to implement such trivial things such as an login or basic interface (and separate all that by module, event handling, data, etc.). I just don't want to make a dojo application by using only an index.html and one javascript file, I could do it, but for maintenance and adding stuff, it will just be a complete mess. With this post, I hope to gain some information on this specific subject and perhaps create a tutorial for dojo on how to start up a real web application. For example, applying the mvc pattern, I think a good application tutorial should have a login example (authentification) and a basic modular interface (like some kind of main container, and on various events, the container ui change for instance with different widget). I'll be working on something on github and posting up when I'm done. If your done before go ahead ;)
thank you.
There is TodoMVC at GitHub:
a project which offers the same Todo application implemented using MV*
concepts in most of the popular JavaScript MV* frameworks of today.
It employs dojox.mvc #PEM mentioned. It's not a typical way of building Dojo applications as dojox.mvc was released just on May 16th, 2011, but it is worth looking at. There is also live demo and tutorial Creating Todo MVC in Dojo:
Overview
Part 1: Models
Part 2: Views
Part 3: Controllers
Also have a look at the source code of Dojo Web Builder (+ article Introducing the New Dojo Web Builder).
Last but not least is Maqetta (sources at GitHub), the most complex Dojo application one can find. Look esp. in maqetta.core.client/WebContent/ directory.
Maybe you have not searched enough?
Dojo MVC :
http://livedocs.dojotoolkit.org/dojox/mvc
http://dojotoolkit.org/documentation/tutorials/1.7/data_modeling/
I just don't want to make a dojo application by using only an index.html and one javascript file
But that's basically what Dojo is for and good at...
If you just want to make cute animation on a plain old html website, rather go for jquery, it's sexier.
Now if you want to do a "real web application" then dojo is the right framework. But you'll also have to learn how to use it.
There are a couple issues with building a sample application tutorial.
First, a sample application with what you have described will need a web server to communicate with. Dojo is web server agnostic, so what technology do you choose to for the sample application? Secondly, a server is now required to make the demo available online, or the person interested in looking at the demo would need to install the web server. As simple as this sounds, it is a barrier and prevents a more novice person from continuing.
Second, even with a web server there are many ways to build/architect a web application.
I think a good application tutorial should have a login example
(authentification) and a basic modular interface (like some kind of
main container, and on various events, the container ui change for
instance with different widget)
From what you have posted, it reads like you are looking for a single page application. There are downsides to single page apps (such as SEO) and creating a sample single page application needs to make it clear to the developer what the downsides of using the sample are. It's not the magic bullet for all Dojo/Web applications.
I have a project up on Github and it certainly isn't ready for primetime, but you can take a look. This is a Single Page Application that uses Java/Spring for the backend server. I am a couple days away from checking in the Spring Pet Clinic example which will demonstrate some of the functionality. I also need to update the wiki to describe how to create a sample application.
https://github.com/cswing/evinceframework
Also, I use the theme tester often to take a look at different widgets. Not entirely what you are looking for, but some who get to this question may find the link useful.
http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/themes/themeTester.html
I would like to know, how powerful/viable are JavaScript only clients based on say, GWT/gxt/vaadin, when compared to DHTML clients such as those made with wicket, tapestry, click etc?
My boss has insisted on using GXT (due to its nice colors and theme) on a project that will most likely become very big with lots of screens. I am against the idea of a javascript only client, especially when the javascript is generated from Java code. I have tried to advice him that we use something like wicket whereby we construct the screens with html but put in ajax where and when neccessary.
How viable is such a JavaScript client? I understand that JavaScript was intended for minor web page enhancements, and not all browsers, especially mobile devices have complete support for JavaScript.
Yes, it is viable for certain applications. Consider Gmail, Google Docs and Google Maps as typical applications where this works, and is probably the most feasible approach.
Some rich UI JavaScript frameworks, such as Ext JS also rely on this technique.
I've built javascript only web apps for ages.
First in SAP projects for big multinationals. And now on a new project:https://beebole-apps.com?demo
So yes it is powerful and viable.
Javascript-only webapp can be extremely powerful, and it's viable for certain applications, say, an Instant-Messenger webapp?
You mentioned that there are lots of screens in your web-app. One of the advantages from GWT/GXT is the fact that you can unit test your UI-layer with JUnit. This is an extra testing you can do on top of, say, Selenium. This is essential if you'd like to make UI testing a part of the continuous integration process, and, as the team grows, you'll definitely want to have tests around to make sure everything works (At least in theory.)
However, if what your boss meant to do is to build an in-house, custom Javascript engine using GWT's JavaScript Native Interface (Link), then I'm not sure...
Another advantage with GWT-like-engine over Wicket is that you can rely on HTML-code-gen to generate standard-compliant (In theory) HTML code. With framework like Wicket, it is hard to ensure every single developer on the team to author good HTML code - Especially when the team gets bigger.
Disclaimer: I'm a member of the Vaadin team.
Our Timeline demo is a good example of what can be achieved with Vaadin and GWT in client side, but I think all of the options presented in this discussions are viable given enough time.
Since you are going to start a big project you should build a simple proof-of-concept app with each of the relevant frameworks. If your PoC includes at least some of the more complex use cases you'll probably can make a pretty informed choice based on the experiences you get while building them.
I urge you to at least evaluate Vaadin. With it you write only server-side Java code and Vaadin will create a slick and professional browser UI for you. Client side can be easily extended using standard GWT (also pure Java), and there are no HTML templates, tag libraries or XML configuration involved at all. A Vaadin UI is fully Ajax'ed and lazy loading out of the box, and it easily integrates with any server side technologies, eg. Spring.
In addition to the development model advantages you get top-notch documentation, a bi-weekly update schedule, a very lively community filled with helpful experts, 100+ useful open source add-ons, and a 10 year old backing company with help on hand should you need it.
I would like to create a database backed interactive AJAX webapp which has a custom (specific kind of events, editing) calendaring system. This would involve quite a lot of JavaScript and AJAX, and I thought about Google Web Toolkit for the interface and Ruby on Rails for server side.
Is Google Web Toolkit reliable and good? What hidden risks might be if I choose Google Web Toolkit? Can one easily combine it with Ruby on Rails on server side? Or should I try to use directly a JavaScript library like jQuery?
I have no experience in web development except some HTML, but I am an experienced programmer (c++, java, c#), and I would like to use only free tools for this project.
RoR is actually one of the things the GWT is made to work well with, as long as you're using REST properly. It's in the Google Web Toolkit Applications book, and you can see a demo from the book using this kind of idea here. That's not to say that you won't have any problems, but I think the support is definitely out there for it.
There's a neat project for making RoR/GWT easy that you can find here (MIT license). I haven't had a chance to try it out yet, but it looks like a good amount of thought has been put into it. One catch is that it looks like it hasn't been fully tested with 2.1 Rails yet, just 2.0, so you may run into a few (probably minor and fixable) errors.
If you are looking to integrate GWT with non-Java backends such as ROR, PHP etc., you should bear in mind that GWT 1.5 now supports JavaScript Overlay types. This feature lets you write classes that can be mapped over the top of native JavaScript objects to easily provide accessor methods for properties of those objects and other extended functionality.
See this link for more details:
JavaScript Overlay Types
So you could return JSON encoded data from your backend via AJAX calls, parse it into a JavaScript Object and then access the data through your GWT Java code using the overlay classes you've created. Or when you render your page you can render static config data as JavaScript Objects and read it in via this mechanism, rather than having to do an AJAX call to grab the data.
If you know JAVA, and have somewhere you can host it (like a tomcat or glassfish container) I would recommend that much more than using Ruby for the back end. The main reason is that then you can share all of your objects, and use the built in RPC mechanism. I've done this for quite a lot of our projects and it's a huge timesaver, not to mention that the code is less error prone, because you don't convert your java objects to anything and then back again.
I have linked my GWT with Rails before, using the to_json function in Rails and then reading the JSON in GWT. It's all supported, but it is far more annoying than just doing the back end in JAVA.
Of course if you have cheap hosting, then Java containers are pretty much out of the question, in which case I would think Rails would be the next best thing.
GWT is very high quality with a great community. However you do need to know CSS if you want to adjust the look of things (you will) - CSS can do a lot of the layout, just like regular web if you want it to. Libraries like GWT-ext or ExtGWT can help a bit as they have stunning "out of the box" looks but for a price (extra size to your app).
You can code everything in Java using GWT, and you can integrate existing 3rd party javascript libraries with it. It's very good. I've never used RoR much though, so can't say anything about that.
If you're experienced in Java but not in Javascript/CSS, then GWT is going to be a lifesaver (unless you want to learn them, of course). CSS has so many little fiddly details. It is not uncommon to spend half a day fixing a 2 pixel misalignment that only occurs in IE6.
I am not sure about how easy it would be to use ROR for the back end... It is possible, I am sure, since GWT ajax communication is just servlets. But they provide some really nice functionality for passing Java objects back and forth which you won't be able to utilize if your server isn't also using Java.
I wrote about some of the disadvantages of GWT recently. Mainly, the disadvantages are: long deployment cycle for changes to some parts of the application and a rather steep learning curve. As a seasoned Java programmer, the second should be less of a problem and if you use a seperate backend, the first is also mitigated (as a complete redeploy is primarily required when you change the 'server' part of the application).
GWT is a wonderful framework with lots of potential. Keep in mind that it's still quite new, though. There are some unresolved bugs that can really annoy you, and they usually require ugly workarounds to get past. The community is great but you'll probably end up with a few problems sooner or later that Google can't answer yet.
But hey, I say go for it. The potential for GWT is awesome, and I bet it's future will be bright.
You should definitely use GWT for a new project (it's pretty easy to use in an old project too).
I my experience it's very fast to learn and use. The compiled javascript code is much better than anything you could ever write by hand and it works fast too.
Another benefit is the ability to debug you're code (which is hell with javascript alone)
This blog has inputs from many experienced users of GWT and have some great discussion points. I personally have huge experience with varied UI Frameworks. I will add my two cents. Lets look at fundamental advantages and disadvantages of GWT
Fundamental Advantage
GWT takes the web layer programming to JAVA. So, the obvious advantages of Java start getting into play. It will provide Object Oriented programming. It will also provide great debugging and compile time checks. Since it generates HTML and Javascript, it will also have ability to hide some complexity within its generator.
Fundamental Disadvantage
The disadvantage starts from the same statement. GWT takes the web layer programming to JAVA. If you know JAVA, probably you will never look out for an alternative language to write your business logic. It's self sufficient and great. But when it comes to writing configurations for a JAVA application. We use property files, database, XML etc. We never store configurations in a JAVA class file. Think hard, why is that?
This is because configuration is a static data. It often require hierarchy. It is supposed to be readable. It never requires compilation. It doesn't require knowledge of JAVA programming language. In short, it is a different ball game. Now the question is, how it relates to our discussion?
Now, lets think about a web page. Do you think when we write a web page we write a business logic? Absolutely not. Web page is just a configuration. It is a configuration of hierarchical containers and fields. We need to write business logic for the data that will be captured from and displayed on the web page and not to create the web page itself.
Previous paragraph makes a very very strong statement. This will explain why HTML and XML based web pages are still the most popular ones. XML is the best in business to write configurations. A framework must allow a clear separation of web page from business logic (the goal of MVC framework). By doing this a web designer will be able to apply his skills of visualization and artistry to create brilliant looking web pages just by configuring XMLs and without being bothered about the intricacies of a programming language. Developers will be able to use their best in business JAVA for writing business logic.
Finally, lets talk about the repercussions in direct terms. GWT breaks this principal so it is bound to fail. The cost for developing GWT application will be very high because you will need multiskill programmers to write web pages. The required look and feel will be very hard to achieve. The turn around time of modifying the web page will be very high because of unnecessary compilation. And lastly, since you are writing web pages in JAVA it is very easy to corrupt it with business logic. Unknowingly you will introduce complexities that must be avoided.
You could also consider Grails ("Groovy on Rails") which gives you the benefits of a Rails framework and the use of the Java VM.
Our team recently asked the same question, and we chose to go with GWT, especially since the designer plugin made working with GWT more accessible to non-java experts on the team. Whoever makes this choice, just beware you DON'T use the GWT Designer plugin !! It has not been updated (in at least a year, apparently) to create a GWT application that is compatible with IE8.
Our team had almost completed our application layouts, which were working perfectly in Chrome, FF and Safari. Then they blew up in IE. IE 7 would load partial pages (but not composite includes), and IE8 was not even able to load up the application. It just hung.
The designer plugin has buttons that allow the user to add CellTable widgets that are not IE compatible (CellTable, DeckPanel, Horizontal Panel, Vertical Panel, among others). These will cause intense pain when the layouts have to be re-done in java without assistance from the designer.
Experienced GWT users love it, but the designer plugin will kill you.