Firstly thank you all for your continued discussion. I would really love to start using this technology in a major new app I'm about to start and the reason I'm asking questions / advice is that I need to determine what the limitations are and whether or not this is a viable option for my use cases.
Note that we have an existing front end in .Net with a Java middle tier serving XML to the client. I have never been happy with this arch and the split of skills, build, test, deployment mechanisms. The .Net front end only exists to give the user's a richer UI experience - but it's a pain. I was hoping that GWT would be the enabling technology to ditch the .Net/Windows. I can see GWT working fine for simple forms or short grids but I must be able to support long grids. I would not put an explicit grid paging based approach in front of the users. The point about DHTMLX or other live-grids being a "paging" approach is true from a technical standpoint, but not true from a user- experience viewpoint and that is what really matters. My eval criteria for grids has been ... - sorting/grouping capability - fast load, which means sub-second rendering of 200 rows of data and no more than 2 or 3 seconds for 2000 rows (this would be worse than my existing .Net solution) In the case of the second requirement I would accept a 'live grid approach' - which would mean that the requirement could be interpreted as... - "fast load, which means 200ms rendering of first 'page' of data for a set up-to 2000 rows and no more than 200ms for any subsequent page" (200ms is effectively instantaneous from a user perspective). My feeling from what I've seen is that where IE (all versions) is concerned, none of the currently available widgets can support sorting/ grouping and perform adequately. --- The bulk loading stuff (http://google-web-toolkit- incubator.googlecode.com/svn/trunk/demo/BulkLoadingTableDemo/ BulkLoadingTableDemo.html) looks interesting but there's no sorting/ grouping. The bulk load API on IE 7 does 2000 rows in <1sec which is great but there's no sort/group. and on chrome I can bulk insert 2000 rows in 200ms which is brilliant except I must use IE. --- Re the incubator / scrolltable... See earlier I used the scroll table as a reference .. http://google-web-toolkit-incubator.googlecode.com/svn/trunk/demo/ScrollTable/index.html It's just too slow on IE - worse still the perf actually degrades badly as we add additional batches of rows. IE7 tests ... 1st set of 100 took 7 secs next set of 100 took 15 secs (ie total 200 rows) thirst set of 100 took 27 secs (ie total 300 rows) What I was seeing was an exponential degradation in perf for each batch of additional rows. ---- Given that all the grids I've looked at performs poorly in IE I expect this will rule out GWT for apps like mine where the main deployment env is IE and where grids of more than a few tens of rows are used. ---- >From my angle it looks like JavaScript grid functionality is a non- starter because of Microsoft. The other browsers (particularly chrome) are an order of magnitude faster. Is there any benefit to Microsoft fixing this? I doubt it. Wouldn't the success of GWT for corporates actually distract attention from SilverLight? I'm not a much of a conspiracy theorist but if I were MS then I don't think that fixing IE's obvious perf problems would be high on my list of priorities. ---- Note I would love to be proved wrong on the GWT perf thing for grids. - sorting - grouping - fast (defined above) on IE ---- Right now it looks like the only possible contender for me is a Live- grid approach. Its all so unfortunate - I can get 2000 rows of data into the client with a network round trip, all in less than 100ms but it's taking seconds to render. Does anyone know of a good sorting/grouping live grid demo that allows a variable number or rows to be inserted (for test purposes)? Thanks Again folk, John On Dec 30, 8:50 am, fin <[email protected]> wrote: > Hi John, > > then have a look at the table stuff in the incubator project. That > contains sortable, pageable, scrollable table solutions which can have > bulk renderers. > It's also worth seeing the gwt mosaic project. It's table solutions > are based on the tables of the incubator project (and seems to be easy > to use but it is still under development). > > Best regards, > Tibor > > On Dec 29, 9:58 pm, John Lonergan <[email protected]> wrote: > > > Hi - I've taken a look at the grids in the incubator and they are > > definitely much faster (200ms in IE7). > > > But those grids are very basic. > > > I need a grid that's a bit more functional .. > > - sorting > > - scrolling > > - fixed non-scrolling header row (i.e.header doesn't scroll with rest > > of grid) > > > Are such features available in a fast grid and are there any examples? > > > Thanks > > > John > > > On Dec 29, 1:18 pm, gregor <[email protected]> wrote: > > > > Hi John, > > > > 1) I concur with your timings on that incubator scroll table demo for > > > FF at 3s, but not on IE at 15s: mine does it in 5s. Suggest something > > > strange about your IE set up?? > > > > 2) The DHTMLX example lazily loads rows on demand using what looks > > > like a scroll listener. Overall table size probably calculated from > > > secondary DB query for num rows and overall height of scroll panel set > > > accordingly. So user gets an impression of the overall size of table > > > and can use scroll bar and/or page ip/down & up/down arrows to > > > navigate it. It only ever fills in the visible portion. Impressive > > > trickery, but IMO the only advantage this has over the more > > > traditional <-prev : next-> button navigation format is user can > > > scroll right down table quickly using the scroll bar handle. But how > > > could user know which records they might hit by doing this? Clever > > > programming maybe but is it good UI design? IMO that is questionable. > > > There are other ways to make sense of large data sets in the UI. > > > > 3) Although it takes 3s for FF and 5s for IE to render the incubator > > > scroll table example for 100 rows, my little test does this in both > > > browsers <0.5s for 200 records, about 0.5s for 500, and about 3s for > > > 2000 in FF, slightly longer for the 2000 in IE. OK, mine is running > > > local and the examples are running over the net, but that doesn't > > > account for all of the massive difference. This should be telling you > > > something: tabular data grids can be complicated things, and people > > > have wide variations in requirements for them, so ready made > > > generalized grid components need shed loads of code to make them > > > configurable for everybody's needs. In most cases if you roll your own > > > component from base GWT widgets you will get blisteringperformance > > > for your own use cases by comparison because you can build it to do > > > exactly what you need it to do, and only what you need it to do. > > > > 4) If I wanted to use a ready made component for this I would head > > > straight for the new PagingScrollTable in the incubator. Reason being > > > that nothing makes into official GWT code unless it works as fast as > > > is reasonably possible. GWT makes no compromise on this. What does a > > > user care most about: a) how quickly and easily they can get at the > > > information they need, or b) how pretty it looks in the screen? > > > > 5) If you are using an Ext family grid widget it will definitely run > > > slow because there is heaps of Ext framework javascript running as > > > well as actual widget code. Ext looks great, but does not compete with > > > base GWT forperformanceor reconfigurability. > > > > 6) Paging *is* the answer to this problem: As you can see from your > > > DHTMLX example above, what they do is paging but in a hidden way, i.e. > > > they try to give the impression that the whole 50,000 rows are loaded, > > > but of course in reality they are not, and this is obvious when you > > > play with it because it simply isn't fast enough to deceive the eye. > > > > regards > > > gregor > > > > On Dec 29, 9:30 am, fin <[email protected]> wrote: > > > > > Hi John, > > > > > have a look at the bulk renderer feature of the GWT incubator > > > > project:http://code.google.com/p/google-web-toolkit-incubator/wiki/BulkTableR... > > > > andhttp://code.google.com/docreader/#p=google-web-toolkit-incubator&s=go... > > > > > Best regards, > > > > Tibor > > > > > On Dec 29, 5:32 am, John Lonergan <[email protected]> wrote: > > > > > > Hi - yep there was a problem in my test program but now that that's > > > > > ironed out I'm getting ok'ishperformancein FF3 and Chrome however in > > > > > IE the perf is poor. > > > > > > All the time is spent populating the grid / rendering. > > > > > > IE is the target deployment platform - they only have IE installed. > > > > > > Have been looking for online samples that are useful for demonstrating > > > > > a sort of problem I'm seeing. > > > > > > I found this useful demo that allowed me to verify that what I'm > > > > > seeing re rendering times is not just a result of my dodgy program. > > > > > >http://google-web-toolkit-incubator.googlecode.com/svn/trunk/demo/Scr... > > > > > > I tested by clicking "Add 100 rows" on the Data Manipulation tab. > > > > > > The relative timings are ... > > > > > IE 15 secs > > > > > FF3 3 secs > > > > > Chrome 1 sec > > > > > > This is consistent with what I see for my grid test. > > > > > I'm using com.extjs.gxt.ui.client.widget.grid.Grid > > > > > > I suspect that the more basic a grid I use, the quicker the rendering > > > > > will be. > > > > > > However, I assume one can achieve something similar to the 'big data > > > > > set example" from > > > > > DHTMLXhttp://www.dhtmlx.com/docs/products/dhtmlxGrid/samples/loading_big_da... > > > > > Where we fetch the data in chunks on-demand. > > > > > > However, I've noticed that the time taken to insert new rows on the > > > > > GWT grids I've played with takes longer the more rows are inserted. > > > > > > Are there any good examples of what can be done with big grids without > > > > > paging? > > > > > > On Dec 22, 2:15 pm, gregor <[email protected]> wrote: > > > > > > > Hi John, > > > > > > > Yes, compile/browse ought to give you goodperformance. A 200 > > > > > > Person[] > > > > > > returned over RPC should enable you to resize and show all of them > > > > > > in > > > > > > a Grid within about 0.5s in web mode (it works in compile/browse > > > > > > too). > > > > > > Example code below. If it isn't doing so, then something is wrong > > > > > > with > > > > > > what you are doing I think, not the RPC layer. > > > > > > > regards > > > > > > gregor > > > > > > > public class SandBox implements EntryPoint { > > > > > > > private VerticalPanel layout = new VerticalPanel(); > > > > > > private ScrollPanel scroller = new ScrollPanel(); > > > > > > private Grid grid = new Grid(1, 5); > > > > > > > private Button fireBtn = new Button("Fire", new ClickListener() > > > > > > { > > > > > > > public void onClick(Widget sender) { > > > > > > GenericListServiceAsync proxy = > > > > > > GenericListService.App.getInstance(); > > > > > > proxy.getPeople(new AsyncCallback() { > > > > > > > public void onFailure(Throwable caught) { > > > > > > Window.alert("RPC call failed"); > > > > > > } > > > > > > > public void onSuccess(Object result) { > > > > > > Person[] people = (Person[]) result; > > > > > > loadGrid(people); > > > > > > } > > > > > > }); > > > > > > } > > > > > > }); > > > > > > > public void onModuleLoad() { > > > > > > > scroller.setHeight("" + (Window.getClientHeight() - 100)); > > > > > > scroller.setWidth("100%"); > > > > > > scroller.add(grid); > > > > > > > grid.setBorderWidth(4); > > > > > > grid.setWidth("100%"); > > > > > > > layout.add(fireBtn); > > > > > > layout.add(scroller); > > > > > > layout.setSize("100%","100%"); > > > > > > RootPanel.get().add(layout); > > > > > > } > > > > > > > private void loadGrid(Person[] people) { > > > > > > > grid.resize(people.length,5); > > > > > > for (int i = 0; i < people.length; i++) { > > > > > > Person p = people[i]; > > > > > > grid.setWidget(i,0,new Label(p.getPersonId())); > > > > > > grid.setWidget(i,1,new Label(p.getFirstName())); > > > > > > grid.setWidget(i,2,new Label(p.getLastName())); > > > > > > grid.setWidget(i,3,new Label(p.getEmail())); > > > > > > grid.setWidget(i,4,new Label(p.getPhone())); > > > > > > } > > > > > > } > > > > > > > } > > > > > > > On Dec 22, 11:57 am, John Lonergan <[email protected]> wrote: > > > > > > > > Thanks Gregor > > > > > > > > I've hit the Compile/Browse button - I understood that caused the > > > > > > > app > > > > > > > to run in 'web mode' (as opposed to hosted). > > > > > > > > Or do I need to run it in a standalone tomcat to get a perf boost? > > > > > > > > John > > > > > > > > On Dec 19, 1:48 pm, gregor <[email protected]> wrote: > > > > > > > > > Hi John, > > > > > > > > > It sounds like you might be testing this in hosted mode. If so, > > > > > > > > be > > > > > > > > aware that hosted modeperformance, especially where RPC is > > > > > > > > concerned, > > > > > > > > bears no relationship whatever to deployedperformance. If so, > > > > > > > > deploy > > > > > > > > your example and I think you will be amazed at the difference. > > > > > > > > Note > > > > > > > > building grids, trees etc involves drawing an order of > > > > > > > > magnitude more > > > > > > > > HTML boxes than there are items to display. 200 odd Persons > > > > > > > > should > > > > > > > > display < 0.5s when deployed, but go up to 1000+ and > > ... > > read more ยป --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
