141–147 of 147 posts
I'm always amazed to see how people who give advice (and good ones in this case) are totally unable to follow them on their websites. 296 http requests. 1.85mb transfered. Yslow grade D. So yeah, these are good advices. In fact, the OP should follow 'em if he wants to "survive".
Earlier quoted context omitted.
he says at the bottom "And a disclaimer – don’t look at the source code of my web page – I rarely work on that, and is using an old blogger template. lol"
Quality code ages well. Old is not an excuse for crappy or slow, neither you can so easily disclaim your own code. Would you take fashion advices from someone with horrible and smelly clothes ?
Agree with half, but don't worry about: JS MVC frameworks: MVC in JS is almost always overkill. HTML5: Most of the web doesn't have support for it yet. Optimization: Sure, but don't preoptimize so rather go looking for the tools once your app tells you it's slow. Also minified JS is great to save a tiny bit of bandwidth and obfuscate, but damn it's a pain to debug your live site.
Unless your bread and butter is modern web apps (ie. json driven sites with websockets/long polling) which, at least in my neck of the woods, seem to be rapidly becoming the norm.
Without backbone.js it would not be possible for me to do any of my current client's projects on the timelines I'm doing them, simple as that.
That said, learning every client-side mvc is probably a mistake too. Just research them and learn the one that you feel is best.
Earlier quoted context omitted.
There is no future in GWT. Even Google is running away from it and is working on Dart now. Having worked with GWT for some time, it's a subpar model. Perhaps it's a flawed execution of the concept, but it has extremely long compilation times, the development mode crawls (so developing with it is slow)--at least for a sizable project. Furthermore, it's not as easy to use external JS libraries (you have to create wrapp…
>> There is no future in GWT. I think there is. This doesn't look like the site of a failing project: https://developers.google.com/web-toolkit/ >> but it has extremely long compilation times, the development mode crawls When you go to create the deployment package it's slow. When doing development, which is most of the time, it's fast to me. I can change things in the client or server code, save and see the results…
It's not that the project is about to fail, it's that even with that I still don't see a future. The project is mostly driven by the now-disinterested Google and a bunch of large companies with huge and different GWT-based frameworks (SmartGWT, Vaadin, Sencha GXT). The latter players only have an interest in keeping the core of GWT alive, not in advancing the regular GWT experience. Other players are small and on the whole don't seem to be contributing in promising ways (in my opinion). For example, the GWT-P framework, despite some good ideas, is quite verbose and provides false time savings.
>> I can change things in the client or server code, save and see the results instantly.
I work on a medium-sized code base (compared to some enterprise code I used to work on in the past). I am using 1-yr-old top-of-the-line MBP with best-available SSD and let's just say we disagree on the definition of the term instantly. I experience anywhere from 15 to 30 second waits on refreshes (that trigger recompilation), plus server restarts if server-side hot code deploy fails. That's far from instant.
>>>> it's inexcusable for a 2012-era framework to not have a quality form validation library available.
>> http://code.google.com/p/gwt-validation/
I disagree. Have you actually used that library? All it does is data validation. That's not my problem.
My problem is tying that into forms and the UI. Compare that to http://docs.jquery.com/Plugins/Validation, compare that to validation provided in SmartGWT's forms.
Have you written forms that had to be validated? GWT CellTables that had to have contents be validated?
There is another GWT validation library out there that helps with forms/tying into GWT controls, but it's quite lackluster.
>>>> The other downside of GWT is that it's written in verbose Java
>> That is a huge, major win dude. Seriously. What else would we all program the web in? JavaScript?
Java is verbose and you have to recognize that downside. I will often pay those costs of verbosity on the server-side in exchange for performance. Someone else here gave a good alternative perspective, but yeah, JavaScript.
>>>> ...Java, with plenty of non-DRY stuff.
>> DRY is a principle, you can repeat yourself or not in any language you choose.
The problem with GWT, and this applies to the non-DRY comment, is that they did not aggressively go after eliminating that. They just said, "it's Java, things are just going to have to be verbose." C'mon, you wrote a Java-to-Javascript compiler for Pete's sake, surely you can put some talent into making the core development experience better! Especially in the face of competition like jQuery or Rails.
Creating two files per page/view sucks (or 3 files with GWT-P, be warned), or coding up your views w/o UI binder, you end up coding the layout of the page in pure Java (verbose and far from directly relatable to the layout). I already mentioned the pain of doing GWT RPC calls in my previous comment. I could go on all day.
Of course, DRY is a principle. Use it!
Earlier quoted context omitted.
Steve Klabnik's is pretty good: http://designinghypermediaapis.com/ And there is this one http://www.amazon.com/Building-Hypermedia-APIs-HTML5-Node/dp... also which is longer but more detailed. You don't need to know anything about node to understand.
I took a look at Steve Klabnik's a few days ago. Honestly, I couldn't get into it - I'm not sure why, but I felt it was disorganized. I felt there was no way to really jump in from the beginning, get a good ground-level understanding, and then progress to more advanced topics. It felt more like a collection of articles targeting people with various backgrounds and levels. Maybe I'll be back to it after I've read anot…
Earlier quoted context omitted.
I _hate_ web apps/sites/services created with GWT. They result in a) overcomplicated UIs b) assets which are completely opaque. Which runs contrary to the promise of the web: simple stuff that anyone can learn from. I realize this is an old saw that the young turks of HN probably don't care much about, but it is damn sad.
the promise of the web is "build once , run everywhere" , not "read the source code, ripoff that work". Nobody cares how it is done. the web is a plateform , the only things that matters is that the software runs on that plateform, without the need of going native.
A great deal of people care how it is done.
This is against the grain, but it is obvious to me that the way forward for web development is to rise above Javascript and simple DOM mangling, which is what most of these popular tools assist with. Javascript does not scale complexity and manipulating DOM elements directly is both error-prone and a lousy programming paradigm. We need something in between that offers a sane development model and deals with the compl…
Ragarding your edit: A startup called famo.us( http://famo.us ) is focusing on exactly this (canvas based UIs) however I'm not completely sold that this is the future. It's an awful lot of wheel reinventing. They're doing it in the name of solving performance for HTML5 apps and for creating apps with rich UIs which would be more similar to interfaces we see today in games rather than traditional DOM based UIs. Howeve…
At famo.us, we're focusing on turning the top level DOM elements into something compatible with the app approach that is capable of being made performant. However, we're not going to throw the baby out with the bathwater. DOM and the original ideas behind HTML are still valuable. It's just time to reassess the role of apps and how to make it so they can live in the same space as documents (i.e. the browser viewport), especially when they are ephemeral apps, because the "install" is dead. It's been usurped by the almighty hyperlink.