Posts Tagged ‘Web’
The competition in the server side programming department is getting tougher with each month, especially with the recent popularity of NodeJS. However let`s look how everything began.
PHP appeared about 20 years ago, in 1995 and ever since then it has been a number one language for back-end developers and has gathered a big community behind it. For a long time there wasn’t any good reason why not to use PHP: it`s rather easy to use PHP, it`s supported by the majority of hosting companies and it has become the most commonly used language in terms of number of websites powered by it.
Of course, everyone has his own truth: one coder will praise the speed of NodeJS while the other will be devoted to the stability and long history of PHP. But let`s have a look at strong sides of both for you to decide whether to concern yourself with the so popular nowadays NodeJS or not.
PHP strong sides:
– Huge community and tons of materials for all programmers, from a beginner to an advanced coder.
– Deep code base. The most popular platforms for building websites (WordPress, Drupal, Joomla) are written in PHP. Not only are the platforms open source, but so are most of their plug-ins.
– Easy to find a hosting company. PHP has been the industry standard since the stone age and any hosting company still surviving is bound to be compatible with it. For Node.JS you still need to make a little research.
– Simplicity. PHP can be run inside of the same file as html.
– Speed of coding. For most developers, writing PHP for Web apps feels faster: no compilers, no deployment, no JAR files or preprocessors — just your favorite editor and some PHP files in a directory.
– Mixing code with content. You just open up PHP tags and start writing code. No need for templates, no need for extra files or elaborate architectures.
– No client app is needed. All of the talk about using the same language in the browser and on the server is nice, but what if you don’t need to use any language on the browser? PHP is a way out.
NodeJS strong sides:
– Speed. NodeJS is blazing fast compared to PHP. This is where Node really kicks assJ.
– Separation of Concerns. NodeJS separates fundamental components up giving a clear separation of concern across controllers / routes, models and views.
– New and fresh. It’s newer in comparison to PHP and has been developed by programmers who have full knowledge and understanding of modern web applications, from the server to the client, and that means more modern features.
– JSON. NodeJS is a powerhouse for JSON. Accessing SQL is possible and there’s plenty of plugins that make it possible, but JSON is the lingua franca for interacting with many of the latest NoSQL databases.
– Gridlock. NodeJS uses a callback structure to pass logic from one asynchronous call to the next meaning we never have to worry about spawning new threads or even considering the deadlock process. Almost no function in Node directly performs I/O, so the process never block which is a major implication for scalable systems.
That is a difficult decision when it comes up to decide which language or tool to choose. But NodeJS worth considering and it`s proved by the fact that Node is getting more and more popularity every day. And what is your opinion on NodeJS, is it the future of web?
Today I would like to draw your attention towards Business viewpoint in comparison of SharePoint and Drupal.
So let the story begin.
Initially SharePoint was created as a document management system and has over time, through continuous expansion and new features, taken on some similarity to a content management system. So for today SharePoint is being positioned as not only an intranet platform, but also a web framework that can power big sites and be on the same playing field as other larger CMS platforms. Drupal in its turn has been developed to provide the foundation to build something, whether it’s a corporate website, web-shop, customer portal, CRM, intranet or extranet, or all at once. So theoretically, we can admit that since then, Drupal and SharePoint has seen the light, both platforms have been more in each other’s way and the debate of Drupal vs. SharePoint has been part of their history. Still what is a wiser choice?
Time for setup
In this point Drupal knock SharePoint out. Firstly Drupal is based on PHP that makes it very easy to run on any environment. With SharePoint, it needs to run Windows locally to be able to set up even the development environment. If you do not have Windows, you will need run it on VMware or other virtualization software. In this case you will have to beef up your local machine to manage the memory requirements.
Today SharePoint Online definitely obviates the set up hassle for companies not looking for self-hosted solutions. Even so, the configuration steps are not as easy and shiny as they might look on the surface.
Drupal allows to quickly set up an intranet site or something on a public domain in a few hours. From a business point of view, you can get rolling within a few hours!
Integration with other services
In this case SharePoint definitely has serious advantage of how well it integrates with the other Microsoft services. So, if as a company you are invested in Microsoft and its other services, SharePoint is a natural choice. Firstly, you would already have Windows developers and system administrators and secondly, the tight coupling SharePoint offers with other MS services is golden.
Though Drupal can be configured to interact with other MS services, it is much easier in a non-Windows scenario.
While SharePoint solution need to have not only developers but an in-house SharePoint system administrator to be able to carry out deployments, Drupal does not required any extra developer or CPU resources.
Activities beyond intranet
One of the claims of SharePoint is how it helps companies launch multiple websites apart from just setting up an intranet platform. Still to pull this off it requires a humongous number of human resource and the technical ability . The same can be achieved with Drupal but easier.
Maintenance against paid upgrades
SharePoint today is in a much better shape than what it was a few years ago. But the progres has been very slow and every upgrade means digging deeper into your pockets.
With the community based model, Drupal has seen a far better progress in a much shorter time. The progress has not just been in the core platform but also the kind of plugins and extensions for rapid site assembly available to make Drupal a fuller platform.
In the market Drupal being an open source option has a lot of low cost and free available themes, that can be integrated without much effort. SharePoint in its turn charges for the themes and plus designers have to know XSL to be able to tweak the themes.
What do you think who will have more advantages if we compare an open source option with a Microsoft product? JStill it’s important to note that, SharePoint as an online hosted solution is much more affordable than its predecessor downloadable versions. The licensing fee and the developer licenses were prohibitively high which now can be circumvented by going for the online versions.
From business point of view open sourсe solution seems more profitably than corporate one and Drupal wins. Still if we compare them from technical point of view…who knows, may be the Microsoft’s family product will gain revenge. It would be interesting to know your thoughts about it.
The Web as we know it have been born and matured on computers, but as it turns out now, computers no longer have dominance in it. According to a recent report by analyst Mary Meeker, mobile devices running iOS and Android now account for 45 percent of browsing, compared to just 35 percent for Windows machines. Moreover, Android and iOS have essentially achieved their share in just five years and their share is getting tremendously larger.
According to some forecasts their worldwide number of mobile devices users should overtake the worldwide number of PC users next year. If forecasts come true, this shift will not only continue, but accelerate. Based on data from Morgan Stanley, Meeker estimates roughly 2.9 billion people around the world will be using smartphones and tablets by 2015.
What does it mean now that more people are accessing the Web through tablets and smartphones rather than laptops and desktops? And is it really a big deal? Anyway, Internet is intended to be accessed from anywhere and thus from any device. Well, it is quite a change at least in terms most people consider the Web and how it gradually adapts to be used on mobile devices.
As mobile devices take over, the use of today’s desktop browsers like Internet Explorer, Chrome, Firefox, and Safari will decline. Mobile browsers are already very capable and will increasingly adopt HTML5 and leading-edge Web technologies. As mobile devices naturally have less screen area, the sites need to function more like mobile apps and less like collections of links. So the sites are likely to look like apps.
Apps may rule
Native apps for smartphones and tablets almost always surpass websites designed for mobile devices because they can tap into devices’ native capabilities for a more responsive and seamless experience. This is most likely to change in the nearest future – most experts agree HTML5 is eventually the way of the future. This is already the status quo in social gaming: for example Angry Birds and Words with Friends. Some services won’t be available at all to traditional PCs — they won’t be worth developers’ time.
Less information at once
Web sites and publishers will no longer be able to display everything new for users and hoping something will catch the user’s eye. Smaller screens and lower information density means sites will need to adjust to user preferences and profiles to customize the information they present. Increasingly, the Internet will become unusable unless sites believe they know who you are. Some services will handle these tasks themselves, but the most likely contenders for supplying digital identity credentials are Facebook, Google, Amazon, Apple, Twitter, and mobile carriers.
Sharing by default
In a mobile-focused Internet, anonymity becomes rare. Virtually every mobile device can be definitively associated with a single person (or small group of people). Defaults to share information and experiences with social circles and followers will be increasingly common, along with increasing reliance on disclosure of personal information (like location, status, and activities, and social connections) to drive key functionality. As the Internet re-orients around mobile, opting out of sharing will increasingly mean opting out of the Internet.
Emphasis on destination
Internet-based sites and services will increasingly function as a combination of content and functionality reluctant to link out to other sites or drive traffic (and potential advertising revenue) elsewhere. These have long been factors in many sites’ designs but mobile devices amplify these considerations by making traditional Web navigation awkward and difficult. Still URLs are not going to die – people will still send links to their friends and Web search will remain most users primary means of finding information online.
Going light weight
As people rely on mobile, cloud, and broadband services, the necessity to do things like commute, store large volumes of records or media, or patronize physical businesses will decline. Businesses won’t need to save years of invoices, statements, and paperwork in file boxes and storage facilities – cloud storage comes as their rescue. Banks will become purely virtual institutions consumers deal with online via their phones. Distance learning and collaborative tools will let students take their coursework with them anywhere — and eliminate the need to worry about reselling enormous textbooks.
Going mobile is an obvious trend today. Experts envisage that nearly every service, business, and person who wants to use the Internet will be thinking mobile first and PC second, if they think about PCs at all. Do you agree? And what other related changes can you imagine?
Many thanks for sharing your thoughts :)
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.
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 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
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!
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.
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.
-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.
It’s surprising that in our blog we have never written about Python frameworks and Python itself either. So, I’ve decided to help out the omission :)
When choosing a framework for site development you have many things to consider. If the criterion is a programming language, for Microsoft and C# followers the choice is clear – ASP.NET. Those who are in love with Ruby don’t have to think too much either – Ruby on Rails will be their choice. It’s much more complicated for Python, PHP and Java developers to make up their mind: the quantity of frameworks here is tremendous.
Firstly, I want to underline the pluses of Python frameworks in general:
- Usage of Python language. I’m sure lots of programmers are pretty tired of praising Python. But to write a site on Python is really faster, cheaper and more pleasantly than on other languages.
- Wide choice. Frameworks abundance can be scaring only for beginners. A professional always welcomes the freedom of choice, as the chance to find what you really need only increases. Besides, choice entails competition, and healthy competition leads to quality improvement of every framework.
- Rapid development. New frameworks emerge constantly, and their precursors either give their way to the younger ones, or continue their struggle for leadership: bugs are fixed, new features are implemented. It differentiates Python community from, Ruby community, for instance, which is represented mostly by Ruby on Rails. Due to the lack of new ideas we can see some standstill in Ruby on Rails development.
- Opensource. They say using quality software on a legal and free basis is really cool :)
For now there are several dozens of Python frameworks. Among them are famous Django, Pylons, Turbogear, and some other interesting ones, as Zope, Twisted, CherryPy.
Today I want to make a short review of the more popular Python framework – Django.
Django was created specially for convenient news site development of The World Company. It had been developed since 2000, but to the general public it was presented only in the middle of 2005. The framework got its name after a Belgian jazz guitarist and composer Django Reinhardt.
Django site is built from one or several applications, which are recommended to be made alienable and interconnected (unlike Ruby on Rails, for example). One of the main Django advantage is excellent documentation, and, I suppose, the biggest community among all the Python frameworks.
When getting acquainted with Django, firstly, his built-in administrator interface wins over. It provides convenient work with the content of a written site. You should change the settings a little bit, then following the link http://127.0.0.1:8000/admin you can start the page through which it is easy to manage the content (for example, to look through the data base content and change it).
Django architecture is a bit different from classic MVC. Controller of the classic model MVC approximately corresponds the level, which is called “View” in Django. Presentation View logic is realized on the level of Templates. Due to this Django level architecture is frequently called “Model-Template-View” (MTV).
For models Django provides an abstraction level which frees from the necessity of writing SQL-requests for getting/saving data to the database. All the tables, that are used in the application, are written as classes in a separate file models.py. Then with the help of these classes methods there happens manipulation of the tables content in the code. Thus, work with database becomes fully object-oriented. Django supports work with the main databases (PostgreSQL, SQLite3, MySQL, Oracle).
Also, it is worth noting about a very flexible way of urls reflection on the application function – with the help of regular expressions.
While developing an application it is convenient to use built-in server. It automatically determines the changes in the files of the project source code and reboots. The result from changes made to the code immediately displays on a browser web-page, but it is not recommended to use it as a working one, as it is single-threaded and do not provide any security measures. For these purposes you will have to set a normal server (Apache, for example).
To be honest till the very end, I will enumerate Django disadvantages as well:
- Though the template language is simple, still it is not very “pythonic”
- Not very convenient work with AJAX
- There can emerge some difficulties while replacing components (if you are in bad relations with regular expressions, which are used widely in urls reflection, you may want to use another dispatcher). It is widely believed that Django developers quite often invent bikes. Though Django allows doing this easily and quickly.
Although Django is one of the most popular Python frameworks, do not forget that framework is just an instrument; the choice should depend on the task set firstly, and only after that on its popularity.
Thank you for consideration. As usual, I would be happy to see your comments :)