Altabel Group's Blog

Posts Tagged ‘JavaScript

Within a short period of time since its initial release in late 2009, Node.js has gained the interest of thousands of experienced developers, grown a package manager and a corpus of interesting modules and applications, and even became the reason for a number of startups to appear. You may have heard about node.js, or read articles claiming how great it is; you may have even read some technically focused explanations on why it is so good.

So let’s try to understand what it is about this technology that makes it interesting to developers. And what the commercial pluses of adopting Node.js when developing and deploying web applications.

I’ve carefully look through a number of forums and experts’ opinions in these regards. Below you could find some main reason why it is worth to use Node.js.

* Node.js is a platform for writing high-performance, scalable web applications and network programs in JavaScript. It has an asynchronous, non-blocking, programming model for lightning-fast speeds and enables the use of JavaScript on the server-side so that both client and server run using the same language.

* Node.js was designed to be great at transporting small bits of information around the Internet very quickly, and in real-time. Server-side events, instant messaging apps, real-time games, and collaboration tools are all great example of this.

* Also the reason to use Node.js is based around the idea of not waiting on things. Instead of waiting for a db query to return results, it just triggers a DB query and sets a callback event. Then, while the query is processing, your program can be doing other things (like handling another request). This is what makes Node.js seem so fast.

* Node.js allows designing of scalable applications at a very high speed. The importance of scaling is going to be at a premium for all applications going forward. One of the secrets to Node’s massive scalability is the event-loop. This construct, which is fundamental to the architecture of Node, provides a completely different model for the handling of client connections than those of traditional web server technologies. The event- loop, which your Node.js applications are naturally built upon, transparently treats the connections from your clients extremely lightly. The memory usage per client is negligible, and as such a single Node.js server can handle hundreds of times more clients than a server with other languages.

* Node.js provides non-blocking libraries for database, file and network access. Since I/O is not a fundamental part of JavaScript, nothing had to be taken away to add them. Python’s Twisted and Ruby’s Event Machine have to work around some basic language components in order to get similar evented behavior.

* In addition to the performance wins Node gets “for free” by using the V8 JavaScript engine, the event loop model itself allows Node servers to handle massive concurrencies in network connections very efficiently. It often approaches the benchmarks achieved by high-performance reverse proxies like Nginx (which is also based on an event loop).

* Unlike PHP, Node.js is not “web centric”. Node.js is a general-purpose JavaScript runtime with a host of powerful libraries — one of which happens to provide an HTTP/HTTPS server implementation. With the Node.js it is easy to build command line clients and other TCP/IP servers. This could characterize Node as a quite flexible one, but at the same time, since Node.js isn’t HTTP-centric, you may find yourself having to implement code to do things once provided for you by the framework.

These are only some of the reasons I could provide and answer the question why this library gains popularity and worth to be working with.

Hope this information would be of interest and of use to you. Please feel free to share your thoughts and opinions why we would need to use Node.js. By the way how you think what to expect for it the future?

Kind Regards,
Natalia Kononchuk – Business Development Manager (LI page)
Natalia.Kononchuk@altabel.com
Altabel Group – Professional Software Development

JavaScript has been popular with the developers for a number of years and has been more discussed than jQuery. However it seems to me that we should also pay attention to jQuery as, I bet, we could find a number of interesting facts about it.

Let`s start from the brief history of the two.

Initially JavaScript was called LiveScript and was invented by Netscape. In 1996 Netscape decided to change its name to raise the popularity of the language by combining it with Java. At that moment Java was used to prepare individual plug-ins. Despite the fact that JavaScript developers have tried to recreate the same syntax and functionality, as in Java, between the two languages, there are many differences. The most important difference is that the Javascript – client is an interpreted scripting language. It runs in the browser without first compilation, which is a mandatory action for programs written in Java…but it is another story.

So JavaScript is a scripting language that is mainly used for website development and client side validation.

The most common use of JavaScript is to write functions that are included in the HTML to interact with HTML elements. For example:
- Sending HTML page data to server using AJAX;
- Animating HTML element;
- Validating the HTML form;
- Storing user information that may help for Web Analytic, Ad tracking etc.

As for jQuery, when it came out in January 2006, from first sight, it looked like a cute hack and in general jQuery was seen as a passing fad. Because the chaining stuff looked like a bit gimmick and the library didn’t look like it would cover all of the bases. Still over the past months we could see that the first impression was wrong, because jQuery encapsulates an extraordinary range of common functionality, and provides a clever plugin API for any functionality not included by default. And the most important thing is that the using of the library obeys best practices and plays well with other JavaScript code.

Mostly jQuery focuses on designers and inexperienced developers, still it could be of interest to experienced programmers as well. Here I will try to enumerate the reasons why:

1) Element’s selecting. Every jQuery operation starts from selecting one or more nodes from the DOM. jQuery’s selection syntax is an interesting hybrid of CSS 1, 2, bits of CSS 3, some XPath and a few custom extensions as well.

2) Namespace. The main point in creating a good JavaScript-code for further using is carefully managed namespace. There is a single global namespace in JavaScript and many programmers clog it without any needs. More sensible developers minimize their intervention to the space using different methods. jQuery introduces the only object in the global namespace: function or object jQuery. Everything else is either direct property jQuery or a method of the object returned by a call to jQuery.

3) The $ function. You could say it is not true that that jQuery introduces only one object in the global namespace as there is also a $: the $ symbol is also set up as a shortcut for jQuery. This makes enough gently: if you want to back your former function $ (for example, if you have a piece of code based on Prototype), you can call jQuery.noConflict (), to return to his old the $. At the beginning you could considere the widespread using $ in jQuery is no more than a clever trick. But for some reason thinking of it in terms of the jQuery symbol makes everything seem a lot more sensible

4) Chaining. jQuery development team often boast about supporting this library call chains, reaching statements like «jQuery created in order to change your style of programming in JavaScript». Frankly speaking, this technique is a big turn-off than the road to the future but you can make good use of jQuery while avoiding lengthy chains of methods entirely. Briefly speaking, the chain can be used for some interesting tricks. In addition to using a set of DOM-samples you can use jQuery-end () method to move the object on the stack and exit the current context. It’s a bit hard to explain, but when you use a method that changes the current (object) context (for example, children () or filter ()), you can use the end () later to return to the previous sample.

5) Manipulating with DOM. jQuery offers a few smart ways of making large scale manipulations to the DOM. The first is quite surprising: the jQuery function can take a snippet of HTML which it will turn in to a DOM element.

6) The returned beast. Object, which is returned by the selectors jQuery, could be quite interesting. It represents a set of DOM-elements and behaves a bit like an array—it has a length property, items can be accessed by index and (most importantly) Firebug treats it as an array when displaying it in the interactive console. This is a clever illusion; the collection is actually a jQuery object, incorporating a large number of methods which can be used to query, modify and extend the collection of selected elements.

There are three principle categories of jQuery methods: those that manipulate all of the matched elements, those that return a value from the first matched object, and those that modify the selection itself. If you have Firebug you can try these out interactively: use this Insert jQuery bookmarklet first to load the jQuery library in to any page, then paste the code examples in to the Firebug console. I would like to note a convenient symmetry of these methods: they are used for display attributes (taking 2 arguments passed to or from a number of properties of the object), and to read the values of these attributes (if only one argument). This symmetry is used throughout jQuery, which greatly facilitates the storage API.

7) Unostentatious programming. The best web applications are those that can still function in disconnected scenarios, and the best method to achieve this is using JavaScript, when the events are assigned to elements only after all the HTML-page are loaded by the user. In jQuery there is excellent support for this approach. First, the paradigm of the selectors to select a node is fundamental for jQuery, and for the non-intrusive programming in general. Second, jQuery provides solutions for window.onload problems

8) jQuery and Ajax. jQuery has the best API for working with Ajax. The most simple form of an Ajax call looks like jQuery(‘div#intro’).load(‘/some/fragment.html’). This performs a GET request against /some/fragment.html and populates div#intro with the returned HTML fragment. It’s a neat shortcut, but what if you want to do something more advanced like display an Ajax loading indicator? jQuery exposes custom events (ajaxStart, ajaxComplete, ajaxError and more) for you to hook in this kind of code.

9) Extensions. Considering the whole set of features as standard, it is worth noting that uzhaty jQuery version is only 20 KB, and even less if you use archive (. Gz). Additional functionality that extends beyond this delivery can be arranged with the help of extensions that can (and do) to add new methods to an existing jQuery. If you want, you can do something like this: jQuery (‘p’). bounceAroundTheScreenAndTurnGreen(); The extension mechanism in jQuery provides documented methods for adding them to the system. Simplicity and ease of use have attracted a large community of authors such extensions, the extensions directory has more than a hundred examples. Another nice feature is the ability to add your own selectors as well as their own methods. MoreSelectors expansion adds methods like div: color (red), which, for example, selects all div with red text.

10) Several words about leaky abstractions. When studying jQuery with more respect, you could struggle with one philosophical blocker. In certain cases, jQuery uses a truly unique methods to achieve a particular function: some parts (such as source code selectors) of this library look scary. If you do so , it requires an understanding of how the library works. To understand this, you need to know some basic concepts, the differences between browsers and a set of methods, which the library uses to get around them. No library can protect you 100% against weird browser behaviour, but as long as you have a grounding in the underlying theory you should be able to figure out if a problem stems from your own code, your library or the underlying implementation.

11) Conclusion. I hope enough evidence was brought to have a positive conclusion about jQuery: it is not a regular library. It contains a lot of interesting ideas that can surprise even the most experienced JavaScript programmers and teach them something new. Even if you will not use it in the work, it is necessary to devote some time and explore the “ecosystem” jQuery.

Kind regards,
Elvira Golyak – Business Development Manager (LI page)
Elvira.Golyak@altabel.com | Skype ID: elviragolyak
Altabel Group – Professional Software Development

Nowadays, more and more people use their mobile devices for the majority of their computer needs. That’s why mobile web application frameworks are in high demand for developers. There are several great mobile web frameworks that allow you to create an application with a native “look and feel” interface. Among them are jQuery Mobile, Sencha Touch, iWebKit, DHTMLX Touch, etc. If you have decided to develop a web application for mobile devices and you want to use a client-side framework to achieve this, Sencha Touch (ST) and JQueryMobile (JQM) seem to be the most serious options. What are their strong and weak points? Let’s see.

Sencha Touch

ST is a mobile web app development framework, which is compatible with HTML5, CSS3, and JavaScript. It is really a sensational framework widely used by mobile web developers. With it building web apps for mobile platforms which feel more like native apps is not a problem for a developer.

ST comes with a MVC framework which leads to a well structured code base. It is really a big plus, especially for large projects. Using ST you will likely not have to write a lot of HTML as the DOM (Document Object Model )is generated out of the objects models / widgets that you use. Besides, a wide range of UI widgets to choose from, as well as robust data, layout and component models are at your disposal.

Speaking of device support, ST website actually supports iPhone, Android and BlackBerry. It works really good on iOS. As for Android, it can be slow on large lists. Some problems may occur with Blackberry, so it may be better to choose another framework for this device.

ST also has enhanced support for touch events such as double tap, swipe, hold, pinch and rotate.

Developing on your desktop you should keep in mind that ST does not support all browser engines. You are required to use a browser based on Webkit (like Google Chrome or Safari). You are not able to view Sencha Touch apps in Firefox, Internet Explorer, or any other browser not using the Webkit engine.

ST provides great API documentation and sample demos. But the ST API uses a fairly large (120kb) JavaScript library that is much larger than the jQuery Mobile library.

ST is not easy to get running on the fly. It is almost a purely programmatic model, as you don’t design pages in HTML, but programmatically add elements to a page. So sometimes it’s difficult to make web design separately in HTML.

As for converting sites to work with the framework, it may involve a full front-end rewrite and it is very hard to debug and fix errors in ST.

Pros: MVC codebase; good support of iOS; enhanced support for touch events; great API documentation and sample demos

Cons: is not easy to get running on the fly; a large JavaScript library; problems with converting sites to work with the framework; very hard to debug and fix errors; may be slow on Android; not working properly on Blackberry

jQuery Mobile

JQM is Touch-Optimized Web Framework for Smartphones & Tablets. It is a unified user interface system across all popular mobile device platforms, built on the rock-solid jQuery and jQuery UI foundation.

JQM is really quick to develop with. You can just start with clean HTML markup and then apply “progressive enhancement techniques” or extra HTML element attributes to integrate mobile features into an existing semantic structure.

As for MVC, JQM doesn’t have it. So lot of care has to be taken while organizing the code.

The framework claims to offer a broad level of support across a wide range of platforms, and progressive enhancement for older devices and operating systems. Instead of writing unique apps for each mobile device or OS, the jQuery mobile framework will allow you to design a single highly branded and customized web application that will work on all popular smartphone and tablet platforms.

JQM includes a great AJAX-powered navigation system which enables animated page transitions while maintaining back button, bookmarking and clean URLs.

The framework comes with a CSS theme styling system that enables a simple project to get off the ground very quickly. Then this can be easily extended with your own custom styles. But the CSS theme styling system has limited options so sites built can look similar.

The bad thing is that page transitions and animations don’t feel ‘native’ enough and can be sluggish sometimes.

Pros: JQM is quick to develop with; supports all major browsers and platforms; has a great AJAX-powered navigation system; CSS theme styling system enables a simple project start very quickly

Cons: no given code structure (MVC); CSS theme styling system has limited options (sites may look similar); page transitions and animations don’t feel ‘native’ enough

So after comparing these two frameworks on some points, we see that ST has a given code structure and feels more like coding in Java/C# while jQuery Mobile is more like web with the HTML you write. So it’s better to use ST if you are used to Java/C# and only want to support such devices as iPhone and Android. And if you are a webdeveloper, used to jQuery and HTML and want to support the majority of devices and browsers, using jQuery Mobile seems to be more sound.

And what are your thoughts? I’m eager to know which mobile web application framework will you define as the best solution for developing a web app for a mobile device? Will it be Sencha Touch or jQuery mobile or some other great framework? Thanks and looking forward to your comments!

Kind regards,
Yuliya Tolkach – Business Development Manager (LI page)
Yulia.Tolkach@altabel.com
Altabel Group – Professional Software Development

With the growing popularity of smartphones, tablets and other mobile devices the living has become more comfortable. The different types of apps help us to wake up in time, to entertain reading books, booking tickets, listening to favorite music and just chat with friends without extra expenses. Among the challenges in mobile app market stands also the developing of effective web browsing solutions.

In this article I would like to take a look at DHTMLX Touch framework that helps to create nice-looking and easy-to-use mobile web apps oriented to touchscreen devices.

DHTMLX Touch is a free open source Javascript framework/library for building HTML5-based mobile web apps.
DHTMLX was originally designed to work in traditional mouse-driven web browsers, however since the web moved to mobile devices, it was important to have all parts of the web interface touch-ready and looking good on small screens. After some tests made were approved that DHTMLX library will definitely work in mobile environments with Javascript support too. So the planned mouse was replaced with touch events to provide touch-based user interactions.

Let’s see what the characteristics of DHTMLX Touch are:

-compatible with the main web browsers for mobile platforms that support HTML5;

-free under both GNU GPL and commercial Licenses;

-lots of technical samples with the source code that simplify studying how the UI elements work;

- expanded builder tools:
Skin Builder – an online tool that allows you to build mobile web apps through a user-friendly, drag-and-drop interface. Since v.1.2, you can save your design or share it by sending an URL.
Visual Designer - a simple online tool that provides an easy way to choose the skin for you app and customize the skin colors. A set of predefined skins is included.
Touch UI Inspector – a free extension for Google Chrome that provides a handy visual tool for monitoring the inner state of DHTMLX Touch JavaScript components on a web page.

-server side is based on the on dhtmlxConnectors (the same that used for DHTMLX Ajax library) that simplifies client –server communication;

- simplified scheme of CSS editing.

The current version of DHTMLX Touch framework took a long way from the release of its first components dhtmlxTree and dhtmlxGrid in 2005-2006 to become a complete tool that covers the most required aspects of modern application interface. Three months ago in September, 2012 was presented the updated version 1.2. And now we will see what are the new features and improvements were added:

* Bug fixing – more stable and faster performance, better compatibility with the latest iOS and Android platforms;
* Updated visual designer tool: new Unitlist component, new charts, and the ability to share and save your design;
* Auto-complete for IDEs: Microsoft Visual Studio, PHPStorm, WebStorm, NetBeans, Aptana Studio, Eclipse, and others
* Multiple fixes in form validation logic
* Better memory management: automatic destructors clean up the memory, which helps to prevent memory leaks if the app has a complicated inheritance structure
* Better support of full-screen mode

Many companies around the world make the preference towards DHTMLX saying that it’s very simple, flexible and easy-to-use with a live support forum.

If you have already an experience working with DHTMLX Touch framework or heard something about using it, feel free to share your thoughts/experience by leaving a comment.

You can also have a look at new features of DHTMLX Touch framework and the samples of apps already implemented following the link to the official website http://dhtmlx.com.

Thank you for your attention,
Kind regards,
Katerina Bulavskaya
Altabel Group – Professional Software Development

Java has been around for a while. Soon after its initial inception, Sun started to push the platform towards the web. Now many years later, there are dozens of web frameworks and every now and then the same question pops up: which Java web framework is best.

No framework is perfect, they all have their merits and they all have their breaking points. There is not a single web framework out there that will work for all requirements out there, still there could be found arguments why one framework is better than others and for what types of applications. So let’s have a look at most viable Java web frameworks:

Servlets and JSPs

Some developers say that JSP technology is seriously outdated, while others see it from a little other point of view. The fact of the matter is that Servlets and JSPs do nothing for you – you do everything including mapping request parameters to objects and validating them.

Even with a big variety of frameworks out there, there is still a place for Servlets & JSPs. Smaller web applications are still quickly and cleanly built using them and you don’t need any external dependencies either. The only side note is that you do it properly, which means using Servlets to invoke business logic, using JSPs to generate the view and having JSPs contain no Java code, only JSTL tags and if you want custom tags.

Pros: good for a few pages/functions to implement
Cons: outdated

Javaserver Faces

Some hate it, some love it. The main reason most people hate it is its steep learning curve and the fact that people use it for all the wrong purposes. Speaking of the right purpose, JSF is primarily aimed at being used to build web components for enterprise applications. It is excellent for creating complex user interfaces as the framework takes care of wiring UI components to backend classes with automated validation and transformations going on. Due to its stateful nature you even have an object representation of the web UI available to you server side.

JSF itself is only the base actually. It is designed to be extended, and many third parties do just that. On top of JSF you also have JBoss, Richfaces, Icefaces, Primefaces, Oracle ADF, Apache Tomahawk, JBoss Seam, Omnifaces, etc. They all share the fact that they extend core JSF with more functionality, which usually comes in the form of Ajax controlled “rich internet components”. Jboss Seam is unique in that list as it does not actually aim to extend, but “seamlessly wire together” many frameworks and technologies to the enterprise platform.

Pros: Good for medium to complex enteprise webapps where full control over the front end is not a requirement. If the application is built and designed around a solid backend, JSF 2.1 is your friend.
Cons: Not an easy material. JSF is hard, and there isn’t rich online documentation. If your application aims around a rich and dynamic web 2.0 front end, JSF is not your friend.

Spring framework

Spring framework is not quite a ‘web framework’, but it is unique. IT shares JBoss Seam’s aim in wiring together many different technologies, both frontend and backend. You can use it as an alternative to Java Enterprise Edition technology, but you are just as free to wire Spring and JEE technologies into the same application.

So what does Spring offer itself? A bunch! It has a bean autowiring system to replace (or extend) the dependency injection model as it exists in the JEE specification. It also has an incredibly strong security model. Additionally instead of manually constructing objects, you “inject” them from a Spring managed context. Next Spring has a strong emphasis on the Model View Controller pattern. Spring provides default controller types for example, but you can also implement your own. As for the model layer the framework can setup JDBC, Hibernate, JPA, etc. for you and it can even manage the sessions and transactions. And finally it offers a built in web front end framework with easy to use annotations. I guess there is much more to add to this.

Pros: Excellent for building and maintaining large enterprise applications that also target other legacy systems and technologies. Spring is so flexible you’ll have the least trouble adapting it to whatever you already have floating around. Also there is a huge community around Spring.
Cons: Clunky due to its hugeness. There is also a big amount of legacy that the framework has to drag around.

Struts 2

Struts 2 is actually quite a clean and neat framework. If all you want to do is create simple web applications, “web 2.0″ or otherwise, then it isn’t a bad idea at all to consider Struts 2. But it has limitations. The security model is weak. In this world of web heightened security demands, the framework does nothing to assist you or to help you prevent doing it wrong.

Pros: Good for web applications that do not have high security demands but will be a mix of complex forms and dynamic frontend pages. Low learning curve.
Cons: Weak security

Wicket

A Wicket application, although targeting the web, develops like a Swing application. You work with components instead of a “backend and a frontend”. The separation between the two layers is almost taken away by Wicket. Instead you think in events. A user presses a button, what is supposed to happen? Anything you would basically do with Javascript using other frameworks, in Wicket you write it all using Java code. That is because it all happens server side, but the framework makes it seem like it all happens client side.

Wicket is also friendly to the developer. It integrates nicely into IDEs and even has built in support for hot-deployment making it far easier to change and debug your applications. Also boring and cumbersome features like making your application multilingual is made incredibly easy.

Pros: Wicket can handle most webapp needs including those that are oriented on the back-end and those that are oriented on the front-end.
Cons: Weak documentation (including the books); the alternative API design.

GWT

GWT offers incredibly powerful browser user interface capabilities; using it you can create the coolest web front ends with relatively little work. Google creates most of its own online web services using GWT.
On top of GWT itself Google also provides you a wide range of tools, for example a rich set of plugins for Eclipse. This makes it a complete package that is completely carried by Google itself. This keeps it all tightly integrated and documented, which is a big plus for a web framework.

An added bonus of GWT is its Java to Javascript conversion capabilities. The HTML 5 madness has begun and people are now actually writing whole applications in Javascript. Through GWT you don’t actually have to write your stuff in Javascript itself; you can write Java code instead and still end up with HTML 5 components.

Pros: Good to create highly complex and feature rich web user interfaces
Cons: The framework is different from any other framework out there. When you want to use it you start from scratch, so it may make it hard to adopt it for a new project.

Play Framework

This framework is relatively young. It lays down the rules, brings the conventions and provides you the foundation to allow you to quickly and painlessly develop web applications, without boilerplate, dependency conflicts or layer upon layer of configuration.

This framework can utilize the benefits of the Scala language (but it is also built for the Java language). The same is true for Play 2.0 which is out right now, and more so. This is mostly because the framework is modeled almost entirely after Ruby on Rails 3 including the available tooling.

Pros: stripping away the boring part of Java web development; being completely stateless and Rest-enabled; providing perfect hot-deployment without need for JRebel or JPA entities; integrates with many popular and important web technologies; manages dependencies for you without needing to learn the complexities of Maven; consolidates web dev into a neat package; incredibly easy ORM model based on Hibernate and JPA 2.0, with an additional layer that takes away the cumbersomeness.
Cons: The programming model is quite counter-intuitive; navigation is based on throwing exceptions. deploying is a bit of a mess using Play as you don’t deploy classes, you deploy the source files. The (alternative) way you manage a Play project makes it difficult to integrate it in for example a JEE application in a way that is easy to maintain.

For sure there are many, many more frameworks to be discussed, but most of them serve the same purpose. Could you pass out your personal recommendation what frameworks is better to use and for what types of application?

Thanks a lot in advance for sharing your advice!

Kind regards,
Aliona Kavalevich – Business Development Manager (LI page)
Aliona.Kavalevich@altabel.com
Altabel Group – Professional Software Development