Slashdot Mirror

You'll find that just about every feature your "essential" library provides has a native equivalent that works across browsers -- even as far back as IE 8.

That's a pretty naive view that over-simplifies the situation. One major use for a framework, for example, is to normalize the behavior of different browsers. Another major use is to provide implementations to create interface elements. Now, obviously, everything is natively supported because the Javascript framework is right there doing it, natively. But why should I write the necessary logic to create a draggable window, or a tree view, or sortable grid, when I can just pull that in from a framework? ExtJS is the kind of framework I'm thinking of. Why should I implement ajax-style uploads inside an iframe when they already did that for me, and I can just set up a form panel, indicate it is a file upload form, and write the important stuff?

Even though I can use a massive ExtJS application on a phone, we're not talking about massive applications per se, we're talking about mobile Javascript. So there are things like Sencha Touch for that. Sure, I could write native applications for every device listed under the supported devices section, but why is it smart to do that when I can write a single codebase that I can package for multiple devices?

Or maybe I'm just not "familiar" with Javascript, or development concepts in general. Hopefully you can enlighten me on the merits of reinventing the wheel every time you create something.

You'll find that just about every feature your "essential" library provides has a native equivalent that works across browsers -- even as far back as IE 8.

That's a pretty naive view that over-simplifies the situation. One major use for a framework, for example, is to normalize the behavior of different browsers. Another major use is to provide implementations to create interface elements. Now, obviously, everything is natively supported because the Javascript framework is right there doing it, natively. But why should I write the necessary logic to create a draggable window, or a tree view, or sortable grid, when I can just pull that in from a framework? ExtJS is the kind of framework I'm thinking of. Why should I implement ajax-style uploads inside an iframe when they already did that for me, and I can just set up a form panel, indicate it is a file upload form, and write the important stuff?

Even though I can use a massive ExtJS application on a phone, we're not talking about massive applications per se, we're talking about mobile Javascript. So there are things like Sencha Touch for that. Sure, I could write native applications for every device listed under the supported devices section, but why is it smart to do that when I can write a single codebase that I can package for multiple devices?

Or maybe I'm just not "familiar" with Javascript, or development concepts in general. Hopefully you can enlighten me on the merits of reinventing the wheel every time you create something.

Progressive enhancement has not at all been abandoned. The majority of frontend developers are constantly thinking about accessibility, usability, writing semantic markup and making simple enhancements with JS, that's the standard these days, you build sites that work on any device, at any resolution with and without javascript.

The majority? Where do you work? Can I get a job there? Most of the developers I've met in Silicon Valley either A. don't have those priorities or B. pay lip service to those priorities but don't implement them competently.

But the time where the web was just web pages is gone. You just cannot build an advanced web app without javascript, it's simply not feasible.

Not everybody wants the rich experience. In the vast majority of cases, providing a non-JS experience is not extra work if you're using best practices to begin with.

When I see things like this, I shake my head: http://dev.sencha.com/deploy/touch/examples/production/kitchensink/

Turn off JS on Sencha Touch's kitchen sink, see a blank screen.

And what for? None of that UI fundamentally requires JS to function. If they'd built it with progressive enhancement instead, the links would still work, just without the animations. The forms would still work, just without the fancy enhancements. But most importantly, the page would still fucking render.

We're currently using Sencha Touch - there are some downsides, the documentation can be woefully incomplete or wrong even (be sure to use the online docs so you get the user comments as well), we've had some issues with migrating between very minor revisions, up until recently it only supported Webkit (2.2 added support for mobile IE as well, I think mobile FF is still not supported) and programming for it is quite different than traditional web programming - Sencha Touch is very much a "my way or the highway"-type of framework, if you try to work outside the conventions you're just asking for it.

OTOH, if you're familiar with MVC-based frameworks and GUI programming with something like Swing (or any modern GUI toolkit really), you should be able to pick it up fairly quickly, and it offers a quite rich selection of GUI elements one would expect in a mobile device. You can use traditional OOP with subclasses and so on, which can help to make your code more maintainable. And theming with Compass is just great. HTH, HAND.

What's that? Facebook produces bad software? Say it ain't so.

This story should be titled, "Facebook's Mobile Team Continues to Suck". These guys were able to put together a half-decent Facebook app, for the noble purpose of demonstrating that Zuckerberg is completely ignorant of technology.

Similar concept, but the other end of the technological timeline is the ExtJs grid control (comes with some excellent docco)

You pick up a whole lot of complexity with the ExtJs framework, but you can pretty much implement a whole spreadsheet on it (someone has!), and it's all with Javascript since it's in the browser...

Might not be the same experience as local spreadsheets (no saving to a file :-( ), but it is extensible.

Similar concept, but the other end of the technological timeline is the ExtJs grid control (comes with some excellent docco)

You pick up a whole lot of complexity with the ExtJs framework, but you can pretty much implement a whole spreadsheet on it (someone has!), and it's all with Javascript since it's in the browser...

Might not be the same experience as local spreadsheets (no saving to a file :-( ), but it is extensible.

Similar concept, but the other end of the technological timeline is the ExtJs grid control (comes with some excellent docco)

You pick up a whole lot of complexity with the ExtJs framework, but you can pretty much implement a whole spreadsheet on it (someone has!), and it's all with Javascript since it's in the browser...

Might not be the same experience as local spreadsheets (no saving to a file :-( ), but it is extensible.

Well Sencha seems to think HTML5 is already ready for prime time. Their fastbook (HTML5 implementation of Facebook) app looks pretty impressive.

ExtJS!!

It has a mobile framework called touch too. You connect to a database using CRUD or the Ext.Direct API (which has PHP and Java libraries available). My favorite framework at the moment.

Note that it's GPLv3 however...so if you're not paying for a license, your code must also be GPLv3 compatible.

Check out some of the demos:
http://dev.sencha.com/deploy/ext-4.0.0/examples/

Here's the mobile touch demos:
http://dev.sencha.com/deploy/touch/examples/production/index.html

ExtJS!!

It has a mobile framework called touch too. You connect to a database using CRUD or the Ext.Direct API (which has PHP and Java libraries available). My favorite framework at the moment.

Note that it's GPLv3 however...so if you're not paying for a license, your code must also be GPLv3 compatible.

Check out some of the demos:
http://dev.sencha.com/deploy/ext-4.0.0/examples/

Here's the mobile touch demos:
http://dev.sencha.com/deploy/touch/examples/production/index.html

Yes, in theory -- anyone else who has the GPL'd source can fork it.

Unfortunately, I can think of another case where this wasn't quite true -- ExtJS 3. For those who don't know the story, basically, they released ExtJS as LGPL, but then switched to GPLv3 ... and started making claims that no one else had ever heard (that you'd have to release all source code to your backend services for using their javascript toolkit, and there were questions of if users downloaded the javascript files, was that 'distribution') Due the the Sencha "interpretation" of LGPL, they then claimed the fork wasn't legal.

For more background:

• http://www.alittlemadness.com/2008/04/24/ext-discovers-step-2-of-the-slashdot-business-model/
• http://ajaxian.com/archives/openext-the-fork
• http://www.sencha.com/forum/showthread.php?33096-License-Change

... and after all of that badmouthing, it seems like they might've wised up, as they now list an 'Open Source License Exemption', so those of us using BSD, artistic, or GPL2 can use it. I guess I'll have to look to see if they're still claiming you have to release your server code:

• http://www.sencha.com/products/extjs/license/

Yes, in theory -- anyone else who has the GPL'd source can fork it.

Unfortunately, I can think of another case where this wasn't quite true -- ExtJS 3. For those who don't know the story, basically, they released ExtJS as LGPL, but then switched to GPLv3 ... and started making claims that no one else had ever heard (that you'd have to release all source code to your backend services for using their javascript toolkit, and there were questions of if users downloaded the javascript files, was that 'distribution') Due the the Sencha "interpretation" of LGPL, they then claimed the fork wasn't legal.

For more background:

• http://www.alittlemadness.com/2008/04/24/ext-discovers-step-2-of-the-slashdot-business-model/
• http://ajaxian.com/archives/openext-the-fork
• http://www.sencha.com/forum/showthread.php?33096-License-Change

... and after all of that badmouthing, it seems like they might've wised up, as they now list an 'Open Source License Exemption', so those of us using BSD, artistic, or GPL2 can use it. I guess I'll have to look to see if they're still claiming you have to release your server code:

• http://www.sencha.com/products/extjs/license/

This whole attitude that computers should not be used to assist with trivial tasks reminds me of how someone who just learned arithmetic might look down on those who use calculators to do arithmetic

Again, you're missing the point. If someone wants to use autocomplete, or any other automated tools, once they have the job, then let them be as productive as they can. The interview is not about being productive, it's about demonstrating the basic skills that let them do the job in the first place. The best way for them to do that is to take away the automated tools that do their work for them.

That being said, in a production environment, I don't see any benefit beyond a time savings to using autocomplete vs. an API reference. Autocomplete makes writing code faster, but your claims about how a popup list of methods would increase your understanding of an API fall a little flat. Autocomplete is no substitute for a reference like this:

http://docs.sencha.com/ext-js/4-0/#!/api

I can scan through that reference and get much, much more detail and insight into both what is available in the API, and how it works (plus links to examples, the complete class hierarchy, not to mention the actual source of the API methods) that you just don't get from a popup list of available methods. Quite frequently I scan that documentation for a class that I'm using just to see which methods, events, etc are available on it. When I find a new problem I always scan the API first to look for methods or events that are going to help solve the problem. With autocomplete I still need a link to the documentation to complete the learning. Might as well skip that step and go straight to the source.

I'm just wondering whether to invest my time in Actionscript or Javascript.

If you're asking that question in 2011, the answer is Javascript. 10 years ago the answer would have been different. I'm not sure which "experimental" frameworks you've looked at, but I would suggest using a mature framework like ExtJS version 4. You won't find better documentation in a Javascript framework, and it even has a version specifically for mobile devices (Sencha Touch).

I'm just wondering whether to invest my time in Actionscript or Javascript.

If you're asking that question in 2011, the answer is Javascript. 10 years ago the answer would have been different. I'm not sure which "experimental" frameworks you've looked at, but I would suggest using a mature framework like ExtJS version 4. You won't find better documentation in a Javascript framework, and it even has a version specifically for mobile devices (Sencha Touch).

It pains me that people still mark comments like that as Insightful. Look up Sencha/ExtJS or another full-featured framework with UI components. Javascript plus CSS and images can do a ton of extremely useful things that we used to need Flash for. I'm not positive about this, but I think the only thing that ExtJS 4 uses any Flash components for is for some really nice charting tools. That could change with support for canvas, but one of the advantages of ExtJS 4 is that it works in IE6. Granted, like all things Javascript, IE6 takes its sweet goddamn time to do anything, but it does work.

I take that back about the charting, apparently ExtJS 4 uses SVG and VML, not Flash (unless the browser doesn't support SVG or VML).

Did I mention the API Docs?

It's not 2001 anymore, even though we have to support a browser from 2001 doesn't mean our tools need to be that old also. There's nothing Insightful about telling people to target IE6 and use Flash for anything "fancy". There are hundreds of thousands of people using the applications I've built with ExtJS (older versions, no less), and I bet a lot of them use IE6.

It pains me that people still mark comments like that as Insightful. Look up Sencha/ExtJS or another full-featured framework with UI components. Javascript plus CSS and images can do a ton of extremely useful things that we used to need Flash for. I'm not positive about this, but I think the only thing that ExtJS 4 uses any Flash components for is for some really nice charting tools. That could change with support for canvas, but one of the advantages of ExtJS 4 is that it works in IE6. Granted, like all things Javascript, IE6 takes its sweet goddamn time to do anything, but it does work.

I take that back about the charting, apparently ExtJS 4 uses SVG and VML, not Flash (unless the browser doesn't support SVG or VML).

Did I mention the API Docs?

It's not 2001 anymore, even though we have to support a browser from 2001 doesn't mean our tools need to be that old also. There's nothing Insightful about telling people to target IE6 and use Flash for anything "fancy". There are hundreds of thousands of people using the applications I've built with ExtJS (older versions, no less), and I bet a lot of them use IE6.

It pains me that people still mark comments like that as Insightful. Look up Sencha/ExtJS or another full-featured framework with UI components. Javascript plus CSS and images can do a ton of extremely useful things that we used to need Flash for. I'm not positive about this, but I think the only thing that ExtJS 4 uses any Flash components for is for some really nice charting tools. That could change with support for canvas, but one of the advantages of ExtJS 4 is that it works in IE6. Granted, like all things Javascript, IE6 takes its sweet goddamn time to do anything, but it does work.

I take that back about the charting, apparently ExtJS 4 uses SVG and VML, not Flash (unless the browser doesn't support SVG or VML).

Did I mention the API Docs?

It's not 2001 anymore, even though we have to support a browser from 2001 doesn't mean our tools need to be that old also. There's nothing Insightful about telling people to target IE6 and use Flash for anything "fancy". There are hundreds of thousands of people using the applications I've built with ExtJS (older versions, no less), and I bet a lot of them use IE6.

Probably Sencha Touch: http://www.sencha.com/products/touch/

You'll need a webkit browser like Chrome or Safari to see the examples.

You'd be surprised what can be done as a web app these days: http://www.sencha.com/products/touch/demos.php

No need to deal with Apple or Objective C (which I rather like) to get web apps installed on an iOS device.

Especially with tools like this Sencha

If you learn HTML/CSS/Javascript you can target Android/IOS and the Web.

Tools you can use include:
Appcelerator
Sencha Touch plus Phonegap

You can read this article for more information and other options.

You've got to be kidding me.

The parent is modded off-topic, then troll? A link to a method of accomplishing both the OP's objectives is totally on-topic.
I could understand a lack of moderation due to apathy, but wtf is wrong with you, mods? The parent is on-topic, and I don't see how pointing out a system that functions on both android and iOS is any kind of troll.

Perhaps there is something I don't know about sencha touch, which causes it to be an abomination of some kind?
In that case, the proper response is to reply with the missing information, not moderate into oblivion.

The only reason I can see for giving the parent any kind of grief is that it wasn't a clickable link.

--
Whoops, there went my karma...

It's a DOM structure consisting of divs. Here are some examples of the tree components:

http://dev.sencha.com/deploy/dev/examples/#sample-7

and the grids:

http://dev.sencha.com/deploy/dev/examples/#sample-3

It's a DOM structure consisting of divs. Here are some examples of the tree components:

http://dev.sencha.com/deploy/dev/examples/#sample-7

and the grids:

http://dev.sencha.com/deploy/dev/examples/#sample-3