Slashdot Mirror

I don't know how well this would actually work, but it would be nice to develop a web frontend using tools like glade or QtDesigner rather than what I do now with Haml and jQuery.

Then you want aspx with Visual Studio.

Or using traditional application development tools to build a web app?

I like the Web, but I have to admit, GUI toolkits tend to be quite a bit better. I don't know how well this would actually work, but it would be nice to develop a web frontend using tools like glade or QtDesigner rather than what I do now with Haml and jQuery.

I'm very skeptical, though -- there are ways the Web is currently better than many desktop apps. Even ignoring issues like bandwidth and performance, would this give me an app which properly supports things like bookmarking, tabbed browsing, and the back button? Is it just drawing to canvas, or does it take advantage of native stuff?

From the video, the answer seems to be "no, and it's just drawing to canvas." If that's the case, I take back everything I just said, and I hope this is never deliberately used to build a web app. Still a cool idea, though.

Given the history of web development, dynamic languages became widely used mainly out of ignorance, and have remained widely used due to continuing ignorance. There's no technical argument in favor of dynamic languages. They're just used because their users and proponents often don't even know about how much better and easier static languages make the development of both small and large applications.

While I agree with much of your comment, I believe there are reasons for the continued use of scripting languages in web dev, other than ignorance or stupidity.

The web moves fast, and scripting languages, with their lack of compile-run cycle allow quicker development. Things change enough that this is often worth the corresponding drop in execution speed.

Secondly, the widely-used statically-typed languages (Java, C#) are about as non-DRY as you can get, Java in particular. While static typing does not necessitate needless boilerplate, the languages that remove it are only now starting to gain acceptance, and haven't gotten a firm hold on the market (or strong communities) yet.

Thirdly, shared web hosts (where the majority of small businesses and personal sites are hosted) often don't support much other than static files and PHP, possibly ASP (.NET or otherwise, I haven't checked in a while). I've recently switched to doing a lot more static sites generated by Jekyll, simply because GitHub will host it for me for free (and only having to push my git commits to deploy is nice, too). Hosting matters.

Finally, I find that community is far more important than the language itself, and the innovating part of the web community is a fickle beast, but tends to stay in the realm of dynamically-typed languages. It takes a few years to get something roughly as nice as Rails (well... other people like it) or Django, and years are decades in our field. Things like HAML have been ported to .NET and Java, but the development's done in Ruby.

I got it from the actual url on the page in question. Beter ask the person who wrote the page, not me.

It's a content-encoding option. The file itself is transparently compressed if the client supports it. That means if you save it with wget, either wget will send an "accept-encoding" header and decompress it silently for you, or it won't send that header and it'll get the uncompressed version.

Here, try it yourself. It comes out to about 24k, when supported.

Very naive statement there,especially since the url, if you read my original post, is NOT the one you reference.

First, you don't give a URL in your original post.

Second, how is it naive? Watch this:

$ curl -s http://ajax.googleapis.com/ajax/libs/jquery/1.4/jquery.min.js | md5sum
10092eee563dec2dca82b77d2cf5a1ae -
$ curl -s http://code.jquery.com/jquery-1.4.2.min.js | md5sum
10092eee563dec2dca82b77d2cf5a1ae -

Well, surprise surprise, they match perfectly, unless you're seriously going to claim Google is exploiting an MD5 collision -- not impossible, but seems absurdly unlikely. Again, how is it naive to assume that when I ask Google's API for jQuery 1.4, I get jQuery 1.4?

And also totally irrelevant to the original point - a PROPER demo to support the claim that there are no other dependencies would NOT make reference to any other scripts.

Oh, I see. There was that claim. Fair enough.

Of course, as others have pointed out, it's not terribly difficult to remove that dependency, as it seems to only be using it for the load.

HTML != XHTML. Get over it, and stop making "fake" xml

Erm, no, that's real XML. Making it XML enables much easier access to microformats, among other things, and generally easier access from REST clients. It also means that, so long as the document actually is XML, the browser can use an XML parser instead of a raw HTML parser -- and XML parsers are much smaller and faster than HTML parsers.

Putting script tags anywhere else in the document is generally considered bad form because of the existence of document.write. The fact that it exists, even if you don't use it, means that the HTML parser has to completely stop and evaluate the script before it can continue parsing the rest of the document. It's in the head for the same reason you want to put the Content-Type meta tag near the top of the document -- as soon as your browser sees that Content-Type, it has to throw away any parsing its done and re-parse the entire document using the new encoding.

In other words, it's not just a matter of people whining about standards, it's a matter of making the best, fastest pages you can.

It's also not like you have to type more in order to do that -- that's what Haml is for.

z0mg zen! As far as I am concerned it's a nice gimmick. If you are going to 'Zen' up your html, why not go all the way and switch to Haml? You actually code in this CSS-like syntax and let Haml compile it to html for you.

I recommend sass and haml for doing css and html respectively.

http://haml-lang.com/

http://sass-lang.com/

Looks like an automated coding editor, will be nice to use with abbreviated languages like HAML and SASS

"I still have the problem I complained about a few years ago: the problems that arise from mixing client side and server side markup in the same artifact"

Someone needs to start using haml.

#1 and #2 don't seem like they would be a problem, and again, I don't necessarily have a problem with this. It's not ideal, but it works -- though I would much rather they enforce the runtime than the language, so we can use things like MacRuby.

#3 is the retarded part. Xcode uses gcc as a compiler anyway. Why shouldn't I be able to use a third-party IDE, or even a third-party language that has Xcode support?

Honestly, I have never seen the Flash converted projects so I can't comment.

That's beside the point. It would hardly be less asinine for Apple to simply ban Flash-converted projects, but they don't even need that. They could easily reject projects which have been Flash-converted on the basis of the actual shoddy code, not simply because they've been Flash-converted.

The real point here is that they're now dictating what tools you can use to an insane, OCD, micromanaging level. This means they're now disallowing anyone from using any third-party preprocessor, Flash or not, even one written specifically for the iPhone.

Let me put it this way: If I don't like some aspect of Javascript, I can always write a preprocessor for it. Hell, I don't like working with raw HTML, so I use things like Haml, which actually output better HTML than most people do manually. But if I don't like some aspect of Objective-C, Apple is effectively telling me tough, I either use it exactly as given or leave the iPhone.

They can probably pull it off, but it's a dick move, and they absolutely are swinging their weight around and using and abusing every bit of good will and marketshare they have.

If what others have said is true - Adobe simply wraps Flash run-time into ObjC wrapper - then it is only given that Apple would be pissed. If Adobe really translates Flash project into a ObjC/Cocoa one (what is very highly unlikely) then the Apple's wrath is really unjustified.

Also beside the point.

Again, if there's something wrong with the generated code, they can simply enforce coding standards which disallow it, and reject apps on that basis until Adobe fixes it.

The problem is that with this ruling, they've disallowed any implementation of the latter option, by anyone, for any purpose -- it's not just Flash, it's everything.