14 Jun 2012 9:39 PM #1
Can't see why Ext Js and Sencha Touch are separate
I've noticed the need for combining Sencha Touch and Ext JS a while back but just didn't say anything as I've read in several places of others asking the same thing, even at the conferences, and Sencha always seemed to have no intention of merging them.
Windows 8 is now reportedly sharing technology that powers their smartphones and based on the web-stack just as Linux Gnome is trying to replace several core components based puely on the web-stack, no to mention the hybrid thin apps that are becoming dominate from languages and frameworks like Qt and ActionScript as well as server frameworks like Drupal designed to handle thin-app creation.
Getting to the point, It's unnecessary for Sencha to provide Sencha Touch, which mainly just supports touch -based apps and only for mobile devices running Chrome based browser then provide Ext JS, which supports no touch-based events but can be run on almost anything.
This is bad for the developer trying to make an app that will run on all devices which will support touch-based technology and mouse/keyboard technology (But the biggest part is that this is where the world is heading towards, Windows 8 is a good example as they're almost entirely touch-oriented further encouraging the drive to touch-based alternatives)
This isn't just inconvenient for the developer but it's also inconvenient for Sencha, apart from Sencha touch have it's differences, most of it is the same. This means when you create new documentation for one product you also have to create the same documentation for the other product, minus a few differences. This has to slow down development or prioritize one or the other.
Sorry for such a long post but instead of just suggesting that they merge, I decided to give several reasons of why and how it could benefit Sencha as well.
I speak English, ちょっと日本語を話します
14 Jun 2012 11:52 PM #2
Good read, I second this! This should be the way forward!
15 Jun 2012 3:13 AM #3
15 Jun 2012 7:02 AM #4
1. Sencha Touch has the luxury of dealing with only HTML 5 browsers, whereas Ext has to go back to IE 6
2. Sencha Touch is free and Ext is not.
I am not sure I understand your point.
15 Jun 2012 4:12 PM #5
That's what I was mentioning, it seems to me that Sencha Touch was created to grasp the latest features available in today's browser. Although largely based off Ext JS they wanted to exclusively fill in the spot that was lacking in Ext JS which was mobile-device specialty and touch-based support.
The problem is the exclusion, Sencha Touch takes full advantage of HTML5 since it's target browsers all support it allowing it to get much sleeker, nifty, and faster than Ext JS. What I was mentioning above is that, by doing so, they're separating themselves from a vastly growing market of non-mobile touch based devices.
I was suggesting a median point largely benefiting users, developers, and Sencha which combines Ext JS (All of it's backwards compatibility and mouse/keyboard events) with Sencha Touch (All of it's sleek features like device profiles and special touch-based components/events). In doing so, everybody's happy. Sencha has one product they can put full-development time into, Developers have one product they can work with (For example, a touch based app with touch-based components that also respond to mouse/keyboard events if the user decides to use it maybe a touch-buton that also has a rollover effect), finally the target audience for the final app tremendously grows.
If pricing is a problem, modulate. Have one central product but Sencha Touch modules included or not and Ext JS Modules Included or not (This includes the open-source or paid for version of the module), this skips licensing issues and pricing issues (if one or the other conflict simply include one) - modulating also won't mess up they're app architecture conformance.
Some desktop apps (like thin clients apps or apps designed for audiences who maintain the latest browser [programmers, security, etc]) need to use Ext JS but don't need the backward compatible features, only HTML5 features, my example above will also work for them since they can use one central product with the latest HTML5 Components dis-concerning themselves with browsers not in their target range.
I speak English, ちょっと日本語を話します
1 Jan 2013 8:55 PM #6
Ext JS and Sencha Touch
I totally agree. I actually started learning Touch then Ext JS, only to find that a lot of the concepts are exactly the same. I think the difference between the 2 is blurring over time and there will come a time it will not be easy to tell the difference. For simplicity, I think there should just be one product covering the range of devices (from touch to desktops) as one continum. This will benefit everyone. Obviously, pricing will have to be adjusted accordingly.
3 Jan 2013 3:04 AM #7
In my opinion ExtJS needs to become more touch-friendly.
I think merging Sencha Touch and ExtJS is not practical at this point in time. Merging the layout systems is prohibitively complicated (and a nightmare for testing). The UI elements are also very different (try using Sencha Touch apps with the mouse, it's painful).
However, as you point out desktops and laptops are becoming touch-enabled, and touch will be standard across all PC's in just a few years, because it doesn't cost much to add and people will look down on PC's that don't have it (feature will flow down from the high-end). This means that all web apps will need to handle touch scenario's well. Either sencha gives us the tools to do this, or we will have to hack them ourselves.
I've already had to hack touch support in some of my ExtJS modules, because customers simply don't accept that their touchscreen kiosk running IE is incompatible with all of our (Sencha) development tools.
When it comes to ExtJS, what I expect is necessary as a minimal effort:
- Logic to replace "hover" behaviors with touch behaviors
- Theme to up-size UI elements so they are finger-friendly. Think about how to make the standard theme touch-friendly without making it look like a cartoon (as sencha touch does on desktop browsers)
- Handling of touch events as first-class event citizens
- Support touch drag in addition to mouse drag
So, Sencha, time to pick up the ball and run with it. Let's do a proper touch strategy on desktops, instead of the current "just use Sencha Touch" non-solution.