As an (ex-)AI researcher now into survivalism, the future looks very exciting. I'll just need to start building an underground bunker and my own killer robots and AI companion that helps me "protect" the other humankind from the evil AIs. Mine will be nice, obedient, and good for everyone, of course. I just hope that the lawmakers understand that or me and my AI companion have to find ways to persuade them. Buahhahhahhaa.
Music itself is largely a social parasite that feeds on various cognitive triggers for opportunities or rewards. It is much like a masturbation device used to trigger sexual reward mechanisms. At its best, music relieves frustrations.
I only say largely, as music also has social functions, akin to giving a masturbation device as a gift to others, or using a masturbation device in group sessions to further social cohesion. Only coincidentally, music concerts are more popular than "jackathons".
Going further with the analogy, music industry is not very different from porn industry, neither in how it abuses people's primitive reactions, nor in its ruthlesness. And to say that music industry is just as dependent on musicians, like Albini, as porn industry is on porn stars. They are free to do something else, but they choose not to.
I'm sure you can use various radar-blocking materials to build walls in a garage, not just wood and plastic, but also metal. So what's so special in factory-made ones that they can't be penetrated by this radar? Is it patented? Or a government secret?
You are right, there is usually more chattiness than in apps where more application logic is handled on the client-side. While there's apps where you absolutely want to minimize that, it's not really a problem in many or even most cases, and many apps have bigger considerations. One big problem in pure client-side coding is that you'll expose more application logic to the client-side, where anyone can snoop it, and need to be more careful with security issues.
You can also do client-side coding much to the extent that you need in Vaadin apps, by implementing complex components or entire views in GWT or JavaScript code, and then just syncronizing the changes as you like. That's actually what you need to do if you want to enable offline mode in Vaadin TouchKit apps.
I wouldn't quite say mouse events, as that includes low-level events such as mouse move events. Vaadin usually sends somewhat higher-level events, such as clicks on button components (not all buttons) and selection changes. You can lessen those by setting components as non-immediate. Sure, there's one case in drag-and-drop handling where even mouse move events can be sent.
Instead of writing JS both on client and server, the Node.js approach, you can write Java on both - that's how Vaadin Framework approaches web applications, by using GWT Java-to-JavaScript compiler for the client-side part. And usually you don't need to write ANY client code, and all client-server communications are completely invisible. You're just writing a UI in Java and can forget most of the client-side peculiarities.
Vaadin is also pretty flexible and allows mixing the approaches to a great extent, allowing JavaScript client-side widgets and other JS integration. You're also free to use other languages than Java for many client-server tasks, such as for REST services.
Not to mention that you can just as well use Scala and such for the server-side.
"Font" is a typographical concept in printing, it doesn't apply to writing by hand, in which you would call them different "scripts" or styles of writing. But yeah, the article is rubbish, apparently based on translating tekstaus to "texting".
This article could be a complete misconception, based on a translation error. The article says that Finnish children will only be taught "texting". In English, texting usually means writing SMS messages and such. The article refers to a Finnish article, where they talk about "tekstaus". In Finnish, "tekstaus" means writing block letters (or print writing) separate letters by hand. That's different from cursive, where the letters are joined.
According to Wikipedia, in English-speaking countries, children also learn block writing first and MAY learn cursive. It doesn't mention how common it is.
If so, this article is nonsense.
The currently taught Finnish cursive is not very different from "tekstaus" anyhow. I personally nowadays mainly use the older cursive, for the exact reason that it has become rare.
Where's Jed? Why isn't anyone mentioning Jed? It's got Emacs bindings, it's really light-weight, works on command-line, and is available by a simple apt-get.
Perhaps they should study whether the main problem is talking in the phone or simply one ringing. Digging the annoyingly ringing phone out of your pocket could be a bigger risk than talking in it.
How to prevent that? Good question.
Handsfree devices are also rather useless, especially if you are driving with automatic gear, and often result in much more distraction than just holding the phone. Fumbling when you attach the phone in the holder and especially fumbling with an earphone can be really dangerous.
Microsoft is not buying Nokia, only the Devices & Services division of Nokia, which includes its phone business. However, that might not prevent Nokia from setting up a new phones business. Perhaps it doesn't make much sense, as Microsoft does get the right to use Nokia brand for 10 years, so re-entering phone business would be rather confusing for Nokia.
Now, if the Android phone is made by the Devices & Services division, it will be transferred to Microsoft, and the Android products may be terminated at some point. It's hard to say - Microsoft could be trying to confuse the market somehow - with existing pantent licensing by Android phonemakers and the ongoing patent cases, Microsoft may try to shake Android markets with a cheaper device for which it has all the patent rights - it now can use all Nokia's phone patents as well, so making phones is almost patent-free, unlike for other Android phone makers who have to pay licensing fees to Microsoft for certain patents. So, making low-cost Android phones could be much cheaper for Microsoft than for others. And, as it doesn't use Google Play, it would bring no revenue to Google.
I'm one of the guys who got the phone two days ago. You can read my quick review here.
To summarize: the user interface based on swiping works quite nicely, even if a bit confusing at first, and the phone works OK as a minimalistic smartphone. On Day 1, there still are quite many bugs and usability issues that need to be worked out.
Compared to Android or iOS, the visual simplicity of the user interface views is extreme, no buttons or decorations almost anywhere. When you open the phone app, you just see a very plain call log. In the email app, you just get a list of emails, and when you open an email, there's just a title followed by text. On the downside, views are often rather over-simplified, so that things are hidden too well, and workflows to get to what you want are often a bit complex and unintuitive. There's no status row that is always visible, system settings aren't accessible immediately everywhere, but you need to go to the start screen, etc.
Some critical features such as WiFi access point missing (or I just haven't found it after poking around 2 days).
Around 30 native apps; some Android apps work just fine, but many do not, and the selection is in practice very limited.
A pack of hair color costs something like $10 at your local store. One problem solved. (If someone has good tips for coloring beard, I'd like to know.)
My guess is that if you want to apply to an organization that uses formal screening process, you're off worse. Networking is the word of the day and if you have a lot of previous work experience, you might already have a professional network. Use it, and sidestep the screening. If not, build your network. Participate in groups, attend conferences, etc. Be active, social, and ambitious, in the right way. Create your own projects, team up, work hard. Target smaller companies that may be more flexible about their hiring practices.
Previous accomplishments are not necessarily a proof of anything, the problem is that everyone can boast about their accomplishments, so nobody pays attention to them if they don't know you, but school grades are official and considered "objective". So, your accomplishments only matter to people who know about them - mainly your network.
Of course, you must be able to develop yourself to the tip of your field. You need to show that you have experience about the field - perhaps write a professional blog, or something, be social. Younger people often have more ambition than us older guys, and you have to rebuild that ambition in yourself, even though I know it can be hard. Be proactive, smart, and develop something bright.
There's a much better alternative - Vaadin. It allows pure server-side Java development of Ajax web applications much the same way as you would develop desktop applications with Swing, etc. Vaadin renders the server-side UI in the browser with widgets and a JavaScript rendering engine. However, you can also develop client-code in Java. The Java code is compiled to JavaScript with the GWT Compiler, which is also included in Vaadin. In Vaadin 7, the Java objects are serialized transparently between the server-side and client-side, so you can essentially work with the same objects on both sides.
So, there is no real reason for node.js, unless you're really good at JavaScript and want to work with it instead of Java, or you have some JS code that you need to run on both sides. If you have already made a client-side JS library, you can integrate it with Vaadin quite easily.
I'd really recommend taking a look at Vaadin. It's a server-side Java and Ajax web application development framework that lets you forget most of the web stuff. The Ajax and HTML rendering are all hidden and it's closer to desktop application development than traditional web development. The client-side is based on GWT, so if you want to make new components, you can do it with Java. In addition to the built-in components, there are some 250+ add-ons, so you can most likely find what you are looking for from those.
Check out StoneGate, it offers a GUI where you can drag&drop all kinds of stuff with a very powerful management system. The learning curve is a bit steep, but it's really meant for network admins who use it as a central part of their jobs. I think it has most of the features you're thinking about.
It's really ideal for large enterprise-level installations with multi-homing network connections, but works in smaller installations just as well (I used it also at home). It requires two servers: at least one firewall node (you can build clusters), and a management server (can be your desktop machine). You can do logging on yet another server, etc. They also offer IPS (intrusion prevention system) for detecting nasty behaviour.
I didn't find any good comparison, so I wrote a simple comparison table: http://markogronroos.blogspot.com/2009/08/n900-vs-iphone.html
Looks like N900 wins iPhone easily on hardware specs, though iPhone does have a few advantages (slimmer, possibly better touchscreen). N900 wins on some very important software issues as well, such as Flash and Skype, though iPhone does have much more software (commercial), at least until old maemo software works in Maemo 5 (if it doesn't directly).
My guess is that iPhone will win in usability and responsiveness, but that's just a guess, Nokia has a chance to surprise us there. I'll be waiting for N900 eagerly and will possibly buy it at some point, although my E90 is just 2 years old and has much much better keyboard than even N900...
Oh, I really hate the three-row keyboard concept in N810, N97 and now N900. I've actually had real nightmares about using Nokia's bluetooth keyboard, which also has the numbers and qwerty row combined. That's definitely the worst thing in N900.
Nothing scientifically interesting here. This is just basic 101 mathematical modeling, straight from the text book. They start with the most basic SIR model, building it from the elementary reactions and do the basic analysis: solve the equilibria and determine their stability with eigenvalues. They have just renamed the generic "infected" as "zombies". We did these calculations for dozens of different models as part of course exercises. For some reason, they don't do phase plane analysis, which is a very basic method, for any of the models, which is a bit strange.
I don't see why any scientific magazine would publish such basic text book stuff, except for fun. Sure, it's fun.
LHC is obviously a doomsday machine. Turning it on will immediately destroy humankind in all the parallel universes where it works. Therefore, in the universes where we stay alive, we will always see it fail. The failure proves the parallel structure of the universe.
I've only met one other person IRL who even knew how to code Javascript properly. That's one reason not to use JavaScript. If you want to code browser stuff, use GWT, at least as much as you can. There are 100 times more good Java programmers as there are JavaScript programmers.
And if you're doing Ajax, use IT Mill Toolkit to develop the application as server-side and let the framework handle the Ajax and client-side stuff, and only code any custom client-side stuff with GWT (or with JavaScript if you really need to).
AJAX is incredibly useful, but it's mostly a really clever hack. The need for dynamically updating elements on the web page is definitely there, and AJAX manages to fill that need somewhat. But Javascript/DOM + XML/HTML is a terrible set of tools to build GUI widgets with. [...] there really needs to be a fundamental change that better integrates these technologies. May I suggest: IT Mill Toolkit. It let's you develop application logic on the server-side in a way almost identical to programming desktop applications. You can forget JavaScript, DOM, XML, AJAX, and even HTML. The applications simply load a client-side adapter into the browser that forwards most user events to the server-side application with AJAX calls, and handle only very limited user interaction in the browser. If you need to customize the client-side, for example, to create some widgets, you can use Java and compile it to JavaScript with GWT.
The first time you try to use a cool feature of your favorite GUI widget, and expect it to work the way your favorite desktop widget does, the cool-factor quickly degrades into frustration. I think the only difference (at least with IT Mill Toolkit) is that the appearance of widgets is defined with CSS instead of API methods. That gets you a bit involved with HTML, so it's a bit bothersome, but the advantage is that you get to separate the appearance from the code. And that's very useful, as the graphics designer can do the theming without getting involved with programming. So it's a trade-off.
If you're already into GWT, try out IT Mill Toolkit. It lets you do the same as GWT, but you don't need a separate server-side application: you only write the server-side and the toolkit does the client-side. So, it really simplifies application development. If you have some GWT widgets that you would like to integrate, or to modify some of the standard widgets, the client-side code of IT Mill Toolkit is GWT.
The change is from synchronous to asynchronous web applications. That's about as big a change as writing distributed applications for someone who mostly wrote 1-tier applications. Design is different as is debugging. Actually, there is a solution for that. Take the architecture of IT Mill Toolkit, for example. The application UI logic runs on server-side, and AJAX is just used to turn the web browser into a thin client or a terminal. The architecture basicly makes the client tier invisible to application logic so that programming is practically identical to 1-tier (desktop) applications.
public class HelloWorld extends com.itmill.toolkit.Application {
public void init() {
Window main = new Window("Hello window");
setMainWindow(main);
main.addComponent(new Label("Hello World!"));
} }
And that's a fully AJAX-enabled application. Well, there isn't any user interaction or complex widgets in this program, but you get the idea. Check out the demos for better examples. Some widgets, such as the Table, load just the visible part of the table to the browser, and when the user scrolls the table, it loads more stuff dynamically. So, doing AJAX doesn't require you to bother with AJAX programming.
Debugging IT Mill Toolkit applications is also identical to debugging desktop applications. Just use your favorite IDE, such as Eclipse, to debug the server-side application. If you develop your own client-side widgets, you can do debugging with the GWT Hosted Mode Browser (and Eclipse or some other IDE). IT Mill Tookit's client-side is written with Java and compiled with GWT to JavaScript that runs on the browser.
This is really the direction where AJAX programming will go.
Doing big AJAX applications is not practical with JavaScript. You would need to do both client and server development, handle communications, and do that in two different languages.
Take the approach of IT Mill Toolkit, for example. You don't need to see a line of JavaScript. Actually, you don't need to code anything on the browser, but all the UI logic is done in the server-side application. The JavaScript running on the browser simply turns it to a thin client that does some trivial user interaction in the browser and forwards most of user events to the server-side application. And if you need some custom client-side stuff, you program it in Java with Google Web Toolkit (GWT).
Slashdot Mirror
As an (ex-)AI researcher now into survivalism, the future looks very exciting. I'll just need to start building an underground bunker and my own killer robots and AI companion that helps me "protect" the other humankind from the evil AIs. Mine will be nice, obedient, and good for everyone, of course. I just hope that the lawmakers understand that or me and my AI companion have to find ways to persuade them. Buahhahhahhaa.
Music itself is largely a social parasite that feeds on various cognitive triggers for opportunities or rewards. It is much like a masturbation device used to trigger sexual reward mechanisms. At its best, music relieves frustrations.
I only say largely, as music also has social functions, akin to giving a masturbation device as a gift to others, or using a masturbation device in group sessions to further social cohesion. Only coincidentally, music concerts are more popular than "jackathons".
Going further with the analogy, music industry is not very different from porn industry, neither in how it abuses people's primitive reactions, nor in its ruthlesness. And to say that music industry is just as dependent on musicians, like Albini, as porn industry is on porn stars. They are free to do something else, but they choose not to.
I'm sure you can use various radar-blocking materials to build walls in a garage, not just wood and plastic, but also metal. So what's so special in factory-made ones that they can't be penetrated by this radar? Is it patented? Or a government secret?
You are right, there is usually more chattiness than in apps where more application logic is handled on the client-side. While there's apps where you absolutely want to minimize that, it's not really a problem in many or even most cases, and many apps have bigger considerations. One big problem in pure client-side coding is that you'll expose more application logic to the client-side, where anyone can snoop it, and need to be more careful with security issues.
You can also do client-side coding much to the extent that you need in Vaadin apps, by implementing complex components or entire views in GWT or JavaScript code, and then just syncronizing the changes as you like. That's actually what you need to do if you want to enable offline mode in Vaadin TouchKit apps.
I wouldn't quite say mouse events, as that includes low-level events such as mouse move events. Vaadin usually sends somewhat higher-level events, such as clicks on button components (not all buttons) and selection changes. You can lessen those by setting components as non-immediate. Sure, there's one case in drag-and-drop handling where even mouse move events can be sent.
Instead of writing JS both on client and server, the Node.js approach, you can write Java on both - that's how Vaadin Framework approaches web applications, by using GWT Java-to-JavaScript compiler for the client-side part. And usually you don't need to write ANY client code, and all client-server communications are completely invisible. You're just writing a UI in Java and can forget most of the client-side peculiarities.
Vaadin is also pretty flexible and allows mixing the approaches to a great extent, allowing JavaScript client-side widgets and other JS integration. You're also free to use other languages than Java for many client-server tasks, such as for REST services.
Not to mention that you can just as well use Scala and such for the server-side.
Running and screaming, that's what I'm looking for. So you can bite my shiny metal ass (that I'm gonna build).
Your fellow AI researcher.
"Font" is a typographical concept in printing, it doesn't apply to writing by hand, in which you would call them different "scripts" or styles of writing.
But yeah, the article is rubbish, apparently based on translating tekstaus to "texting".
Ah yes, that too, didn't notice that. So, both the /. article and the referred one ARE completely based on a translation error.
This article could be a complete misconception, based on a translation error. The article says that Finnish children will only be taught "texting". In English, texting usually means writing SMS messages and such. The article refers to a Finnish article, where they talk about "tekstaus". In Finnish, "tekstaus" means writing block letters (or print writing) separate letters by hand. That's different from cursive, where the letters are joined.
According to Wikipedia, in English-speaking countries, children also learn block writing first and MAY learn cursive. It doesn't mention how common it is.
If so, this article is nonsense.
The currently taught Finnish cursive is not very different from "tekstaus" anyhow. I personally nowadays mainly use the older cursive, for the exact reason that it has become rare.
Where's Jed? Why isn't anyone mentioning Jed? It's got Emacs bindings, it's really light-weight, works on command-line, and is available by a simple apt-get.
Perhaps they should study whether the main problem is talking in the phone or simply one ringing. Digging the annoyingly ringing phone out of your pocket could be a bigger risk than talking in it.
How to prevent that? Good question.
Handsfree devices are also rather useless, especially if you are driving with automatic gear, and often result in much more distraction than just holding the phone. Fumbling when you attach the phone in the holder and especially fumbling with an earphone can be really dangerous.
Microsoft is not buying Nokia, only the Devices & Services division of Nokia, which includes its phone business. However, that might not prevent Nokia from setting up a new phones business. Perhaps it doesn't make much sense, as Microsoft does get the right to use Nokia brand for 10 years, so re-entering phone business would be rather confusing for Nokia.
Now, if the Android phone is made by the Devices & Services division, it will be transferred to Microsoft, and the Android products may be terminated at some point. It's hard to say - Microsoft could be trying to confuse the market somehow - with existing pantent licensing by Android phonemakers and the ongoing patent cases, Microsoft may try to shake Android markets with a cheaper device for which it has all the patent rights - it now can use all Nokia's phone patents as well, so making phones is almost patent-free, unlike for other Android phone makers who have to pay licensing fees to Microsoft for certain patents. So, making low-cost Android phones could be much cheaper for Microsoft than for others. And, as it doesn't use Google Play, it would bring no revenue to Google.
I'm one of the guys who got the phone two days ago. You can read my quick review here.
To summarize: the user interface based on swiping works quite nicely, even if a bit confusing at first, and the phone works OK as a minimalistic smartphone. On Day 1, there still are quite many bugs and usability issues that need to be worked out.
Compared to Android or iOS, the visual simplicity of the user interface views is extreme, no buttons or decorations almost anywhere. When you open the phone app, you just see a very plain call log. In the email app, you just get a list of emails, and when you open an email, there's just a title followed by text. On the downside, views are often rather over-simplified, so that things are hidden too well, and workflows to get to what you want are often a bit complex and unintuitive. There's no status row that is always visible, system settings aren't accessible immediately everywhere, but you need to go to the start screen, etc.
Some critical features such as WiFi access point missing (or I just haven't found it after poking around 2 days).
Around 30 native apps; some Android apps work just fine, but many do not, and the selection is in practice very limited.
A pack of hair color costs something like $10 at your local store. One problem solved. (If someone has good tips for coloring beard, I'd like to know.)
My guess is that if you want to apply to an organization that uses formal screening process, you're off worse. Networking is the word of the day and if you have a lot of previous work experience, you might already have a professional network. Use it, and sidestep the screening. If not, build your network. Participate in groups, attend conferences, etc. Be active, social, and ambitious, in the right way. Create your own projects, team up, work hard. Target smaller companies that may be more flexible about their hiring practices.
Previous accomplishments are not necessarily a proof of anything, the problem is that everyone can boast about their accomplishments, so nobody pays attention to them if they don't know you, but school grades are official and considered "objective". So, your accomplishments only matter to people who know about them - mainly your network.
Of course, you must be able to develop yourself to the tip of your field. You need to show that you have experience about the field - perhaps write a professional blog, or something, be social. Younger people often have more ambition than us older guys, and you have to rebuild that ambition in yourself, even though I know it can be hard. Be proactive, smart, and develop something bright.
'nuf of pep talk. More booze, sleep.
Exactly so.
There's a much better alternative - Vaadin. It allows pure server-side Java development of Ajax web applications much the same way as you would develop desktop applications with Swing, etc. Vaadin renders the server-side UI in the browser with widgets and a JavaScript rendering engine. However, you can also develop client-code in Java. The Java code is compiled to JavaScript with the GWT Compiler, which is also included in Vaadin. In Vaadin 7, the Java objects are serialized transparently between the server-side and client-side, so you can essentially work with the same objects on both sides.
So, there is no real reason for node.js, unless you're really good at JavaScript and want to work with it instead of Java, or you have some JS code that you need to run on both sides. If you have already made a client-side JS library, you can integrate it with Vaadin quite easily.
I'd really recommend taking a look at Vaadin. It's a server-side Java and Ajax web application development framework that lets you forget most of the web stuff. The Ajax and HTML rendering are all hidden and it's closer to desktop application development than traditional web development. The client-side is based on GWT, so if you want to make new components, you can do it with Java. In addition to the built-in components, there are some 250+ add-ons, so you can most likely find what you are looking for from those.
Check out StoneGate, it offers a GUI where you can drag&drop all kinds of stuff with a very powerful management system. The learning curve is a bit steep, but it's really meant for network admins who use it as a central part of their jobs. I think it has most of the features you're thinking about.
It's really ideal for large enterprise-level installations with multi-homing network connections, but works in smaller installations just as well (I used it also at home). It requires two servers: at least one firewall node (you can build clusters), and a management server (can be your desktop machine). You can do logging on yet another server, etc. They also offer IPS (intrusion prevention system) for detecting nasty behaviour.
I didn't find any good comparison, so I wrote a simple comparison table: http://markogronroos.blogspot.com/2009/08/n900-vs-iphone.html
Looks like N900 wins iPhone easily on hardware specs, though iPhone does have a few advantages (slimmer, possibly better touchscreen). N900 wins on some very important software issues as well, such as Flash and Skype, though iPhone does have much more software (commercial), at least until old maemo software works in Maemo 5 (if it doesn't directly).
My guess is that iPhone will win in usability and responsiveness, but that's just a guess, Nokia has a chance to surprise us there. I'll be waiting for N900 eagerly and will possibly buy it at some point, although my E90 is just 2 years old and has much much better keyboard than even N900...
Oh, I really hate the three-row keyboard concept in N810, N97 and now N900. I've actually had real nightmares about using Nokia's bluetooth keyboard, which also has the numbers and qwerty row combined. That's definitely the worst thing in N900.
Nothing scientifically interesting here. This is just basic 101 mathematical modeling, straight from the text book. They start with the most basic SIR model, building it from the elementary reactions and do the basic analysis: solve the equilibria and determine their stability with eigenvalues. They have just renamed the generic "infected" as "zombies". We did these calculations for dozens of different models as part of course exercises. For some reason, they don't do phase plane analysis, which is a very basic method, for any of the models, which is a bit strange.
I don't see why any scientific magazine would publish such basic text book stuff, except for fun. Sure, it's fun.
LHC is obviously a doomsday machine. Turning it on will immediately destroy humankind in all the parallel universes where it works. Therefore, in the universes where we stay alive, we will always see it fail. The failure proves the parallel structure of the universe.
And if you're doing Ajax, use IT Mill Toolkit to develop the application as server-side and let the framework handle the Ajax and client-side stuff, and only code any custom client-side stuff with GWT (or with JavaScript if you really need to).
Disclaimer: I work for the company.
If you're already into GWT, try out IT Mill Toolkit. It lets you do the same as GWT, but you don't need a separate server-side application: you only write the server-side and the toolkit does the client-side. So, it really simplifies application development. If you have some GWT widgets that you would like to integrate, or to modify some of the standard widgets, the client-side code of IT Mill Toolkit is GWT.
Disclaimer: I work for the company.
Debugging IT Mill Toolkit applications is also identical to debugging desktop applications. Just use your favorite IDE, such as Eclipse, to debug the server-side application. If you develop your own client-side widgets, you can do debugging with the GWT Hosted Mode Browser (and Eclipse or some other IDE). IT Mill Tookit's client-side is written with Java and compiled with GWT to JavaScript that runs on the browser.
This is really the direction where AJAX programming will go.
Disclaimer: I work for the company, yada yada.
Doing big AJAX applications is not practical with JavaScript. You would need to do both client and server development, handle communications, and do that in two different languages.
Take the approach of IT Mill Toolkit, for example. You don't need to see a line of JavaScript. Actually, you don't need to code anything on the browser, but all the UI logic is done in the server-side application. The JavaScript running on the browser simply turns it to a thin client that does some trivial user interaction in the browser and forwards most of user events to the server-side application. And if you need some custom client-side stuff, you program it in Java with Google Web Toolkit (GWT).
Disclaimer: I work for the company.