BitsAndBuzz

This is the intro of the full blog post TypeScript, from skeptic to convert

We are a small but focused consulting firm that has been developing two to four advanced business cloud and web applications per year for almost a decade, and we have grown to be very mindful about what technologies make it into our recommended tech stack — we are not the kind of consulting company that adopts new technology just because they are hot.

From our experience, it always comes back to these three core principles, Simple scales better, Patterns over frameworks, Runtime first.

At first glance, TypeScript seemed to be the archetype of what we usually avoid, and despite its noble mission statement to add [to JavaScript] without removing [or fixing], we had our original doubts and skepticism, which could be summarized as follows:

• A Microsoft bait and switch strategy?
• Yet another CoffeeScript?
• Angular stuff?
• Can static type be added the JavaScript way?
• Cost v.s. Value?

In its beginning, we could not rule out any of those concerns out for sure, so we decided to give it some time. After a couple of years and many releases, we took a third look this summer, and that was the charm. We turned from being hopeful skeptics to full converts.

Read more on the full blog post TypeScript, from skeptic to convert

Beside of all this, the one thing that sets us apart from others is our passion for all of the details surrounding all aspects of an application experience, from server and cloud architecture to UI responsiveness and HTML5 optimization.

We are convinced that HTML is the technology of the future for a large majority of applications from a business as well as a technical point of view. And the thing we discovered during this three years is that with the right architectural approach, building advanced HTML5 applications for PCs, mobile devices, and tablets can be as efficient and scalable as creating desktop or native type of applications.

To accomplish this vision, we created two open source technologies, Snow, which is a Java lightweight server framework based on Google Guice, and brite, an lightweight and DOM Centric HTML5 MVC framework based on jQuery. Both of these technologies are completely free, fully open source (Apache V2 for Snow and MIT for Brite), and are designed to build high-end modern applications using the best of Java on the server, and the best of HTML5 on the client.

We are going to blog quite a bit to share everything we have learned over the last few years about building high end HTML5 applications. So, feel free to follow us on
Twitter, Facebook, or Google Plus.

Feel free to visit us at BriteSnow.com or contact us at info@britesnow.com

Nowadays, building [rich] Web applications can be quite challenging, as the proliferation of Web technologies has become overwhelming and confusing. The real challenge is that many interesting new Web technologies are being promoted by various groups, and it can be quite difficult for a developer or architect to filter the practical and future-proof ones from the cool and volatile ones.

As a rule of thumb, open technologies tend to be more pervasive and longer lasting (especially for the Internet) than proprietary technologies, which tend to bring more advanced capabilities early on. Consequently, Web application developers need to be pragmatically-open, by choosing open technologies whenever possible, but also by not hesitating to use proprietary ones when required. It is not about being religious about openness or anything else, but rather about being diligent so that one is able to choose the right technology to maximize the chances of success of the target application. In other words, it should not be a personal and emotional decision, but rather a business and rational one.

Read the rest of this entry »

Software technologists tend to learn by oscillating. We never arrive directly at the right solution; we just come closer to it by going back and forth. We always think (or like to think) that our current solution is correct; only to realize, some years later, that we overshot and need to take a few steps back. The evolution of the software application model is a great example of this syndrome. Every technologist knows about the three main application model phases—Mainframe, Client/Server, and Web [1.0]—and many of them think they know what the next phase will be. In fact, two models are currently being promoted. In order to better understand the current trend, it is important to first understand the three original model phases.

1) Mainframe

The first application model was the mainframe;  the client was simply a screen (typically green) and a keyboard that could display and send characters back and forth through a network. The server had all the definitions of the screens (i.e. User Interface), application logic, and data, and was communicating with the client by sending characters (which represented the UI and data) back and forth.

This approach had the benefit of being relatively simple, cost effective to scale, and was easy to manage because the application could be centrally managed. The limitation was obviously that the client’s lack of richness limited the type of application that could be offered. For example, a Google Map on a green screen would have been a challenge to implement.

Read the rest of this entry »

With the emergence of new technologies such as AJAX, Flash, and Silverlight, and popular applications such as Google Map and iPhone, the temptation for developers to fully and deeply animate their upcoming applications has become almost irresistible.

While slick animations and transitions are certainly useful for emotionally driven applications, such as car configurators, and some applications or components such as Google Map and charting, they should not be used as a substitute for a good interactive design. Application developers need to realize that these animations and transitions come at an extra design and development cost (no matter what tool they are using). 

Read the rest of this entry »

Over the last few years, we have witnessed the emergence of a new type of software platform – the Service Oriented Platform (SOP). The SOP concept is to offer an application platform as a network service (inside or outside an enterprise firewall), providing a centralized runtime to execute and manage distributed or centralized applications.

SOP services can range from application aggregation, presentation, linking (e.g, Mashup), provisioning, componentization, and context augmentation (e.g., Social Graph and common application data). As SOPs mature, it would not be surprising to see these platforms offer most, if not all, of the traditional application platform services in a service-oriented manner, such as application testing, versioning, data migration, and much more.

In the consumer space, the best SOP examples would be Facebook, OpenSocial, and Ning. In the enterprise, a good example would be SalesForce.com (including their latest Force.com addition) and some of the newer smaller players such as Coghead, DabbleDB, and BungeeConnect. Note that SOP solutions can be offered as a hosted service (Platform as a Service, aka PaaS), or can be packaged as a product (not as common yet). In many ways, enterprise portal architecture can be considered the SOP ancestor.

We can identify four distinct but complementary main SOP access modes. Most SOP providers (such as Facebook and SalesForce.com) offer more than one access mode. Others, like OpenSocial, have thus far focused only on one.

Below is a simplified visualization of these modes and their corresponding descriptions.

Read the rest of this entry »