There are step-through debuggers like FireBug, but I've never felt the need to use one. You may find such a debugger more interesting, though.:-)
Dont listen to this man. He knows not what he speaks of. FireBug is teh awesome! For one thing, it will keep a nicely parced log of all your HTTP requests to make AJAX debugging easy. For another, it is just awesome.
But yeah... I've never used much of it's step-by-step debugger. For some reason, I've never found the need--could be because javascript stack traces can be a little wonky with anonymous functions. And probably because most of the reasons *to* debug something are because of IE6 being retarded.
The technology is all there as part of the HTML 5 spec. (Look it up over on the W3C or at WHATWG.org.) Canvas, Audio, SVG, and Video all provide alternatives to what Flash does.
How do those help me? Maybe in ten years when the last computer that can run IE6 dies off, yeah. But until then? Those things are all completely useless. Worse then useless, in fact, because somebody might be tempted to use them.
BTW, the above rant comes from someone who makes a living developing and supporting web apps.
And you should be happy because even if you think silverlight & flex suck, it says the market agrees with you. Give it some time and things will be much better.
Dude, go ahead. Try to write a web application that does anything interesting while supporting any browser that has more than 5% marketshare. Go ahead.
Personally, I have far, far greater respect for people who do web development then people who get the luxury of developing for a non-shifting "real" application. Doing web development work is probably the hardest programming you'll ever do. Hard because your entire set of tools suck ass.
Doing "real" development for "real" installable software is trivially easy. Your tools dont suck. Your platform doesn't shift on you overnight and break your crap in new exciting ways. Your language and libraries mostly have good documentation. Your IDE knows what the hell you are doing. It is easy. Real application development is sinfully easy compared to web development.
You have no clue what you are talking about at all. Go do a web app, even something that seems "easy" like say, anything from 37 signals. Come back to me and tell me you still think web developers deserve scare quotes.
DOM is woefully inadequate for any real application development.
Yup. And people can say "Oh, but HTML5 will fix all the problems". Ha! Yeah, right. Even if they pushed the spec out tomorrow, the fancy new thingamajigs, magic tags and CSS3 pixie dust are useless because you still gotta code back to IE6. And I get the feeling that those 25% will probably die in hover car accidents because they were browsing the web using IE6. Some of them will probably be traveling to their vacation homes on mars and kill time browsing the web using IE6.
My current line of thinking is the only way to "escape" our busted state of web development is to just sidestep around it. Enter Flex and Silverlight--two things who have the potential to make web development fun again (just like when IE7 got transparent PNGs;-)
If you think Silverlight and Flex are the same concept as a Java applet, you are behind the times and I question your abilities as a developer. In a few years, unless you learn either Flex or Silverlight, you are gonna have a pretty hard time getting employment at any kind of web company doing something interesting. Sure you can still get employment coding old school static websites, but all the cool kids will be using Flex or Silverlight.
You can bookmark this comment and come back in a year. Within that year, there will be a flood of "hip web 2.0" applications on the market that will use either Silverlight or Flex to get their functionality. Web companies that do not adapt will no longer be able to remain competitive because their development costs will be higher then those who do use Silverlight or flex. Mark my words:-)
With Microsoft's track record of openness and cross platform support, what could possibly go wrong with your plan?
I'd rather take 95% of the "normal people" market and not loose my hair by the age of 50 thank you. You choose to run an operating system knowing full well it wouldn't work with flash or silverlight. Don't blame your mistakes on others or expect them to cater to your decision.
I wouldn't download a plugin for your content, sorry.
And I, and most other websites operating in the real world, dont care about your visit either. You are a tiny fraction of my web traffic and not worth my sanity to target.
I already own Visual Studio and know how to write.NET WPF applications. I'd have to learn a whole different framework and toolkit, not to mention I couldn't recycle my existing C# classes like I can with Silverlight.
Flex has it's advantage in that it is tightly integrated with Adobe's product suite. This means designers are likely to be comfortable with it. Microsoft has never been good in the design area and even with Expression Blend, you are gonna have a harder time finding graphic designers who speak XAML/WPF/.NET.
Sadly, most of our fancy javascript won't work on those ones either. At least on my Razr, HTML is first massaged by some cell phone company proxy server leaving no javascript bits left.
That said, if one are serious about targeting mobile phones, they probably are doing a separate site that is tailored for the constraints. This will probably change in a year or two with iPhones and Androids that can eat "real" HTML.
BTW: I suspect, despite huge political pressure, Apple doesn't do flash yet because they dont want somebody to make a VoIP app that doesn't use the cell phone for calls, or streaming media app that cuts into iTunes downloads. Eventually they'll cave in, but not without a fight.
If it is really very much quicker than traditional AJAX development, I might consider the trade-off worth it.
Find a part of your website right now that has been a bitch to do in javascript and try replacing that. On my website, it is the interaction between TinyMCE and a plugin I wrote to handle how stories are composed on my sites. On Slashdot, that slider control would be a good bet. On Digg, I'd do the "thumbs up/thumbs down" for comment rating as a first start.
One fellow I was talking to here on Slashdot actually kept a separate copy of APIs like prototype for each module. He simply didn't upgrade them unless there was a clear and solid need to do so.
How does that work? What if you want both widgets on the same page?
And that is another damn problem with the world (I'm on a roll). Unless you use something like "Google Code" to server Prototype.js or jQuery.js, a visit has to load the library from your server when odds are good they have it cached already from another website. In my experience, letting google or yahoo do the library hosting has led to nothing but trouble (they'll stall your page load like the analytics tracking cookie does sometimes).
In fact, you have MORE control because you're not at the whim of the plugin/browser maker to continue supporting the old plugin.
I'm gonna argue just for the sake of having fun... but hundred bucks says "Lightbox v6, now requiring Prototype 10.32!" has a bunch of browser bugfixes that will never get back ported to "Lightbox v5, requiring Prototype 9.1". Sure you can do it, but arg.
Good times! I should probably do real work now, eh?
Many complaints people have with Javascript come from people overusing Javascript.
It isn't overuse. It is because they see the side-effects from how fucking hard it is to write robust code for web applications. At least for me, the javascript code I write tends to be very, very brittle when it is done "correctly".
and shouldn't be doing that weird horizontal scroll thing
I'm sure the developers are aware of this. I also bet they go home and kick their dogs every night because their *code* is correct, but thanks to some unknown bug in $RANDOM_BROWSER, it breaks for a good swath of their userbase. Bonus if it is on a platform they cannot easily test on. Some of these are so hard to track down you pretty much have to use remote access software and *interact* with your site on their computer.
If I am still misunderstanding Flex/Silverlight, please correct me. As a web app developer, I would be interested in tools that hide the complexity of HTML/Javascript, but NOT at the expense of forcing my users to install plugins like Flash.
Flash is like a 3 meg plugin that only needs to be installed once. It runs on all major platforms. It is required for Youtube and probably without it MySpace wouldn't work (but probably look a hell of a lot better;-).
Silverlight is a 3 meg runtime that can be installed without exiting the browser and can reload your page once it installs. Like Flash, once the user has it installed, it works everywhere.
My hunch is, outside of the slashdot echo chamber, "real" users dont care about installing plugins. If the watched any of the olympics online, they've already got Silverlight 2 installed. Once a few websites out there offer a compelling reason to install it, everybody will have to install it to function, just like flash.
But dont trust me... go play with silverlight or flex and get back to me. I was skeptical myself, but once I saw how easy it was to swap out complex bits of javascript with in my case silverlight, I started to realize it was exactly what we web dudes were looking for.
But rookie mistakes don't invalidate the usefulness of a language
But of course you are right. I sure learned a lot from that bug, let me tell you! "Dont ever mix & match junk created by javascript libraries". After that incident, I now get kinda iffy about even passing DOM elements loaded with var ele =$('element'); to other framework's methods.
I can't wait for IE6 to die. I think it will only be a matter of 6 - 8 months and we'll be able to stop supporting it
I've been talking to a friend who supports a website that sells "business software". My websites target the "entertainment" crowd. 25% IE6 for me, fucking 55% IE6 for him. That damn browser just won't die.:-(
As for Silverlight, you don't have compatibility problems now
But that is a compatibility problem that is under your control. Just like you dont have to target.NET 3.5, you dont have to "upgrade" your Silverlight app until you are ready. Your web page can request a specific silverlight runtime, not just "the newest" one.
I'd much rather have Adobe or Silverlight change or break their API than a browser breaking their API between versions. I have *no* control over what browsers visit my site and if, say, Firefox3 broke a lot of my code because of an API change, I would be *forced* to fix things ASAP or a visitor would blame my website, not their browser.
If I target Silverlight/Flex and Firefox 3 broke their support for Silverlight/Flex, there would be a *lot* of other websites (say, youtube) that would be broken and visitors would blame the browser, not my website.
In other words, dealing with Microsoft or Adobe's API changes is way, way better then dealing with $RANDOM_BROWSER's API changes you have zero control over.
Even when IE6 is using a cached version of the HTML? In my experiance, IE6 doesn't fire that event when the HTML is cached. It is hard to spot this bug because as a developer, you usually refresh the page to reload the javascript.
I'm confused why you would inject a Prototype DOM object using the TinyMCE way
Lets say you are writing a plugin for TinyMCE that adds a few extra XML tags that represent things like slideshows or a special kind of image. The user clicks on "insert slideshow" in the TinyMCE toolbar and a window pops up where they can choose from a list of slideshows. That window makes some calls back to the server to get the list of slideshows using my existing Prototype AJAX functions. That window also has to use TinyMCE's popup window functions so it can talk back to the main browser window and spit the results into the TinyMCE document.
Bottom line, I made a rookie mistake and created those elements using something like this var old = **function that gets selected text** var ele = Builder.createNode('DIV', {rel='gunk', class='slideshow'});// create new element tinyMCE.selectedElement.replace(old, new);// replace old DOM elements with new ones
Granted that code is paraphrased, but basically, I mixed scriptalicious's "node" with TinyMCE's stuff. Things blew up in crazy ways.
So yes, the mistake was mine. But it highlights my original point. All these libraries have their own slightly different ways of doing things and it gets really easy to make mistakes like I did when you are lazy/up late. Good luck hunting those bugs down too... most of them crop up on IE6 and you cannot use firebug:-)
God forbid you actually have to look at the code instead of making a bunch of pre-built function calls.
I'd wager your own code would probably piss off TinyMCE's node functions just as easily as scriptalicious did. Even if you did things the text-book proper way.
No offense to you pal, but you will be left behind to suck up what little chunks are left.
Between Flex and Silverlight, I strongly suspect we'll see a good swath of "Web 2.0" replacing their javascript code with either Flex/Silverlight replacements. They will do so because developing on either of these platforms enable them to crank out code that is far more stable, faster to develop, easier to maintain. Both of them can run on Browser/OS platforms used by probably 95% of the web.
The "value story" for either of these platforms are so compelling to companies that they simply will not care about you and your rebellious ways.
None of those are the same. Java applets were slow and required a giant runtime. ActiveX was windows only. Flash was for video and Adobe's product suite is installed on designers computer, not developers.
Flex and Silverlight are for developers. The are designed not for crazy animations (though they can be used that way) but as a way to replace the javascript *gunk* that makes web development so frustrating. They are server agnostic and (mostly) client agnostic.
They are designed to enhance not only the user experience, but arguable more importantly, the developer experience.
Play with them... once you see how nice it is to target a stable runtime that weaves oh-so-nicely into your existing applicaiton stack, you'll start thinking of all kinds of places you can replace javscript gunk with cleaner Silverlight/Flex code.
That is because you misunderstand what silverlight and flex are. The are *not* ment to replace HTML or the backend server. What they replace is 90% of the javascript *crap* that is required to do anything "web-appy". For example, Silverlight/Flex are perfect fits to replace the "hidden/show" control bar on the top of each slashdot comment page. The Silverlight/Flex app renders the control and either manipulates the DOM to redraw the comments or fires a javscript event so your javascript code does the DOM stuff instead.
Take this textbox I'm typing in right now. All that javascript to do the preview/edit was probably a pain in the ass (and it still doesn't work right). Replace it with a Silverlight/Flex widget that does the hard stuff.
Basically, Silverlight/Flex are great replacement and suppliment for any kind of widget or AJAX code that you've got now. At least on the Silverlight front, you can craft the control in a way that is almost a drop in replacement for the javascript widget you used to have. Best, since it speaks JSON, the server doesn't even need to know.
Drupal CMS? I'm sure drupal has some kind of WYSIWYG editor like wordpress, right? Replace the javascript editor with a silverlight one. Marvel at how it Just Works and how easy it is to extend over TinyMCE or FCK editor (or whatever that one is).
And if you've got MSDN on your machine already (ala Visual Studio), you can use the much nicer help application thingy instead of the some-what-broken-in-firefox online documentation.
Sure, you could chain the events, but that's ugly. DOM 2 Events already exists, so why not use it?
Dunno, but I'd imagine one reason might be to "standardize" the broken "body onload" event. For those who aren't up to speed in how crappy IE6 is... IE6 doesn't fire the body's OnLoad event when it uses a cached version of a document, it only fires when it loads a fresh one. Grrr....
Another reason I can think of is some of the libraries (YUI comes to mind) offer easy-ish ways of creating your own events. Having a (library specific) standard method to hook events that works with the (library specific) standard way of creating events might be nice.
Seriously, the bloom of incompatible javascript toolkits isn't making my life easy. I've standardized my own javascript code around Prototype (which is used in Lightbox). There are lots of cool jQuery-only and MooTools-only widgets I'd like to use, but I dont want to have clients pull down three javascript libraries for just one page.
And to finish my rant... just wait until your javascript toolkit vendor ships out a new version (prototype 1.6) that isn't completly compatible with it's old one (1.5). Just wait until 1/2 your widget set breaks on 1.6 and half breaks because of 1.6.
I love web development.
I've been playing with Silverlight. Took me a single night to cook up a file upload control that works on IE6,7,8, Firefox 2 & 3, Intel Mac & Windows (even 2000) and will work on any other platform Microsoft targets in the future. It just nestles itself right into my HTML all cute-like with no fuss. You can get your javascript code to interact with it just like a DOM object -- events and all. It is server-side agnostic and since it can serialize/deserialize JSON, it can talk with all the same server-side AJAX stuff my existing client-side javascript code does. In other words, it appears to be trivially easy to replace the javascript widgets with silverlight ones without touching a line of server-side code.
How long would it have taken to do the same file upload code in Javascript? Probably a week and a month of dealing with users running some spyware/toolbar that breaks the production code in insane ways.
I'm in a library. Which MTA do I use when I cannot install software?
When I'm looking at several items, and want them sorted by popularity, I REALLY DON'T NEED to see an animated status bar show up to tell me that the page is being loaded.
But what if you wanted to sort in descending order instead of ascending order? With javascript your browser can sort the list instantly instead of making another request and waiting a few seconds for a reply.
Write an actual program that will merely communicate over the net
For which OS/hardware? How does it install on a locked down machine at the airport?
glorified Visual Basic apps
VB only runs on Windows. The redone version runs anywhere. You are an idiot.
You are a smart person. Web development, in it's current form, is probably the most needlessly difficult, frustrating line of development work you can do.
You are programing against a moving target that you have no control over. Worse, those target platforms can really suck and break in insane ways that you'd never catch because you simply cannot test on every target.
These "anti-flex" and "anti-silverlight" people are gonna get a wakeup call when none of their websites work in lynx anymore. Silverlight/Flex isn't for them, it is to keep us developers from going insane.
Slashdot Mirror
I've been waiting to upgrade to web 3.0. Thanks for first coining the phrase!
There are step-through debuggers like FireBug, but I've never felt the need to use one. You may find such a debugger more interesting, though. :-)
Dont listen to this man. He knows not what he speaks of. FireBug is teh awesome! For one thing, it will keep a nicely parced log of all your HTTP requests to make AJAX debugging easy. For another, it is just awesome.
But yeah... I've never used much of it's step-by-step debugger. For some reason, I've never found the need--could be because javascript stack traces can be a little wonky with anonymous functions. And probably because most of the reasons *to* debug something are because of IE6 being retarded.
The technology is all there as part of the HTML 5 spec. (Look it up over on the W3C or at WHATWG.org.) Canvas, Audio, SVG, and Video all provide alternatives to what Flash does.
How do those help me? Maybe in ten years when the last computer that can run IE6 dies off, yeah. But until then? Those things are all completely useless. Worse then useless, in fact, because somebody might be tempted to use them.
HTML5 will be stillborn. HTML4 is too entrenched.
BTW, the above rant comes from someone who makes a living developing and supporting web apps.
And you should be happy because even if you think silverlight & flex suck, it says the market agrees with you. Give it some time and things will be much better.
Dude, go ahead. Try to write a web application that does anything interesting while supporting any browser that has more than 5% marketshare. Go ahead.
Personally, I have far, far greater respect for people who do web development then people who get the luxury of developing for a non-shifting "real" application. Doing web development work is probably the hardest programming you'll ever do. Hard because your entire set of tools suck ass.
Doing "real" development for "real" installable software is trivially easy. Your tools dont suck. Your platform doesn't shift on you overnight and break your crap in new exciting ways. Your language and libraries mostly have good documentation. Your IDE knows what the hell you are doing. It is easy. Real application development is sinfully easy compared to web development.
You have no clue what you are talking about at all. Go do a web app, even something that seems "easy" like say, anything from 37 signals. Come back to me and tell me you still think web developers deserve scare quotes.
Dammit. This just makes me want to get a drink.
DOM is woefully inadequate for any real application development.
Yup. And people can say "Oh, but HTML5 will fix all the problems". Ha! Yeah, right. Even if they pushed the spec out tomorrow, the fancy new thingamajigs, magic tags and CSS3 pixie dust are useless because you still gotta code back to IE6. And I get the feeling that those 25% will probably die in hover car accidents because they were browsing the web using IE6. Some of them will probably be traveling to their vacation homes on mars and kill time browsing the web using IE6.
My current line of thinking is the only way to "escape" our busted state of web development is to just sidestep around it. Enter Flex and Silverlight--two things who have the potential to make web development fun again (just like when IE7 got transparent PNGs ;-)
If you think Silverlight and Flex are the same concept as a Java applet, you are behind the times and I question your abilities as a developer. In a few years, unless you learn either Flex or Silverlight, you are gonna have a pretty hard time getting employment at any kind of web company doing something interesting. Sure you can still get employment coding old school static websites, but all the cool kids will be using Flex or Silverlight.
You can bookmark this comment and come back in a year. Within that year, there will be a flood of "hip web 2.0" applications on the market that will use either Silverlight or Flex to get their functionality. Web companies that do not adapt will no longer be able to remain competitive because their development costs will be higher then those who do use Silverlight or flex. Mark my words :-)
With Microsoft's track record of openness and cross platform support, what could possibly go wrong with your plan?
I'd rather take 95% of the "normal people" market and not loose my hair by the age of 50 thank you. You choose to run an operating system knowing full well it wouldn't work with flash or silverlight. Don't blame your mistakes on others or expect them to cater to your decision.
I wouldn't download a plugin for your content, sorry.
And I, and most other websites operating in the real world, dont care about your visit either. You are a tiny fraction of my web traffic and not worth my sanity to target.
Silverlight against a C#/ASP.NET backend
I've yet to play, but there is much work getting Ruby and Python to compile down to MSIL and thus able to run on Silverlight.
Both are light years more productive and compelling than HTML and JavaScript in the bulk of the use cases.
But since it doesn't run on some slashdot users custom compiled 128-bit version of Lynx, it is evil and should never be used.
I already own Visual Studio and know how to write .NET WPF applications. I'd have to learn a whole different framework and toolkit, not to mention I couldn't recycle my existing C# classes like I can with Silverlight.
Flex has it's advantage in that it is tightly integrated with Adobe's product suite. This means designers are likely to be comfortable with it. Microsoft has never been good in the design area and even with Expression Blend, you are gonna have a harder time finding graphic designers who speak XAML/WPF/.NET.
It doesn't work on some mobile phones, either.
Sadly, most of our fancy javascript won't work on those ones either. At least on my Razr, HTML is first massaged by some cell phone company proxy server leaving no javascript bits left.
That said, if one are serious about targeting mobile phones, they probably are doing a separate site that is tailored for the constraints. This will probably change in a year or two with iPhones and Androids that can eat "real" HTML.
BTW: I suspect, despite huge political pressure, Apple doesn't do flash yet because they dont want somebody to make a VoIP app that doesn't use the cell phone for calls, or streaming media app that cuts into iTunes downloads. Eventually they'll cave in, but not without a fight.
If it is really very much quicker than traditional AJAX development, I might consider the trade-off worth it.
Find a part of your website right now that has been a bitch to do in javascript and try replacing that. On my website, it is the interaction between TinyMCE and a plugin I wrote to handle how stories are composed on my sites. On Slashdot, that slider control would be a good bet. On Digg, I'd do the "thumbs up/thumbs down" for comment rating as a first start.
One fellow I was talking to here on Slashdot actually kept a separate copy of APIs like prototype for each module. He simply didn't upgrade them unless there was a clear and solid need to do so.
How does that work? What if you want both widgets on the same page?
And that is another damn problem with the world (I'm on a roll). Unless you use something like "Google Code" to server Prototype.js or jQuery.js, a visit has to load the library from your server when odds are good they have it cached already from another website. In my experience, letting google or yahoo do the library hosting has led to nothing but trouble (they'll stall your page load like the analytics tracking cookie does sometimes).
In fact, you have MORE control because you're not at the whim of the plugin/browser maker to continue supporting the old plugin.
I'm gonna argue just for the sake of having fun... but hundred bucks says "Lightbox v6, now requiring Prototype 10.32!" has a bunch of browser bugfixes that will never get back ported to "Lightbox v5, requiring Prototype 9.1". Sure you can do it, but arg.
Good times! I should probably do real work now, eh?
Many complaints people have with Javascript come from people overusing Javascript.
It isn't overuse. It is because they see the side-effects from how fucking hard it is to write robust code for web applications. At least for me, the javascript code I write tends to be very, very brittle when it is done "correctly".
and shouldn't be doing that weird horizontal scroll thing
I'm sure the developers are aware of this. I also bet they go home and kick their dogs every night because their *code* is correct, but thanks to some unknown bug in $RANDOM_BROWSER, it breaks for a good swath of their userbase. Bonus if it is on a platform they cannot easily test on. Some of these are so hard to track down you pretty much have to use remote access software and *interact* with your site on their computer.
If I am still misunderstanding Flex/Silverlight, please correct me. As a web app developer, I would be interested in tools that hide the complexity of HTML/Javascript, but NOT at the expense of forcing my users to install plugins like Flash.
Flash is like a 3 meg plugin that only needs to be installed once. It runs on all major platforms. It is required for Youtube and probably without it MySpace wouldn't work (but probably look a hell of a lot better ;-).
Silverlight is a 3 meg runtime that can be installed without exiting the browser and can reload your page once it installs. Like Flash, once the user has it installed, it works everywhere.
My hunch is, outside of the slashdot echo chamber, "real" users dont care about installing plugins. If the watched any of the olympics online, they've already got Silverlight 2 installed. Once a few websites out there offer a compelling reason to install it, everybody will have to install it to function, just like flash.
But dont trust me... go play with silverlight or flex and get back to me. I was skeptical myself, but once I saw how easy it was to swap out complex bits of javascript with in my case silverlight, I started to realize it was exactly what we web dudes were looking for.
But rookie mistakes don't invalidate the usefulness of a language
But of course you are right. I sure learned a lot from that bug, let me tell you! "Dont ever mix & match junk created by javascript libraries". After that incident, I now get kinda iffy about even passing DOM elements loaded with var ele =$('element'); to other framework's methods.
I can't wait for IE6 to die. I think it will only be a matter of 6 - 8 months and we'll be able to stop supporting it
I've been talking to a friend who supports a website that sells "business software". My websites target the "entertainment" crowd. 25% IE6 for me, fucking 55% IE6 for him. That damn browser just won't die. :-(
As for Silverlight, you don't have compatibility problems now
But that is a compatibility problem that is under your control. Just like you dont have to target .NET 3.5, you dont have to "upgrade" your Silverlight app until you are ready. Your web page can request a specific silverlight runtime, not just "the newest" one.
I'd much rather have Adobe or Silverlight change or break their API than a browser breaking their API between versions. I have *no* control over what browsers visit my site and if, say, Firefox3 broke a lot of my code because of an API change, I would be *forced* to fix things ASAP or a visitor would blame my website, not their browser.
If I target Silverlight/Flex and Firefox 3 broke their support for Silverlight/Flex, there would be a *lot* of other websites (say, youtube) that would be broken and visitors would blame the browser, not my website.
In other words, dealing with Microsoft or Adobe's API changes is way, way better then dealing with $RANDOM_BROWSER's API changes you have zero control over.
Even when IE6 is using a cached version of the HTML? In my experiance, IE6 doesn't fire that event when the HTML is cached. It is hard to spot this bug because as a developer, you usually refresh the page to reload the javascript.
I'm not arguing against javascript..
I'm confused why you would inject a Prototype DOM object using the TinyMCE way
Lets say you are writing a plugin for TinyMCE that adds a few extra XML tags that represent things like slideshows or a special kind of image. The user clicks on "insert slideshow" in the TinyMCE toolbar and a window pops up where they can choose from a list of slideshows. That window makes some calls back to the server to get the list of slideshows using my existing Prototype AJAX functions. That window also has to use TinyMCE's popup window functions so it can talk back to the main browser window and spit the results into the TinyMCE document.
Bottom line, I made a rookie mistake and created those elements using something like this
// create new element // replace old DOM elements with new ones
var old = **function that gets selected text**
var ele = Builder.createNode('DIV', {rel='gunk', class='slideshow'});
tinyMCE.selectedElement.replace(old, new);
Granted that code is paraphrased, but basically, I mixed scriptalicious's "node" with TinyMCE's stuff. Things blew up in crazy ways.
So yes, the mistake was mine. But it highlights my original point. All these libraries have their own slightly different ways of doing things and it gets really easy to make mistakes like I did when you are lazy/up late. Good luck hunting those bugs down too... most of them crop up on IE6 and you cannot use firebug :-)
God forbid you actually have to look at the code instead of making a bunch of pre-built function calls.
I'd wager your own code would probably piss off TinyMCE's node functions just as easily as scriptalicious did. Even if you did things the text-book proper way.
No offense to you pal, but you will be left behind to suck up what little chunks are left.
Between Flex and Silverlight, I strongly suspect we'll see a good swath of "Web 2.0" replacing their javascript code with either Flex/Silverlight replacements. They will do so because developing on either of these platforms enable them to crank out code that is far more stable, faster to develop, easier to maintain. Both of them can run on Browser/OS platforms used by probably 95% of the web.
The "value story" for either of these platforms are so compelling to companies that they simply will not care about you and your rebellious ways.
None of those are the same. Java applets were slow and required a giant runtime. ActiveX was windows only. Flash was for video and Adobe's product suite is installed on designers computer, not developers.
Flex and Silverlight are for developers. The are designed not for crazy animations (though they can be used that way) but as a way to replace the javascript *gunk* that makes web development so frustrating. They are server agnostic and (mostly) client agnostic.
They are designed to enhance not only the user experience, but arguable more importantly, the developer experience.
Play with them... once you see how nice it is to target a stable runtime that weaves oh-so-nicely into your existing applicaiton stack, you'll start thinking of all kinds of places you can replace javscript gunk with cleaner Silverlight/Flex code.
That is because you misunderstand what silverlight and flex are. The are *not* ment to replace HTML or the backend server. What they replace is 90% of the javascript *crap* that is required to do anything "web-appy". For example, Silverlight/Flex are perfect fits to replace the "hidden/show" control bar on the top of each slashdot comment page. The Silverlight/Flex app renders the control and either manipulates the DOM to redraw the comments or fires a javscript event so your javascript code does the DOM stuff instead.
Take this textbox I'm typing in right now. All that javascript to do the preview/edit was probably a pain in the ass (and it still doesn't work right). Replace it with a Silverlight/Flex widget that does the hard stuff.
Basically, Silverlight/Flex are great replacement and suppliment for any kind of widget or AJAX code that you've got now. At least on the Silverlight front, you can craft the control in a way that is almost a drop in replacement for the javascript widget you used to have. Best, since it speaks JSON, the server doesn't even need to know.
Drupal CMS? I'm sure drupal has some kind of WYSIWYG editor like wordpress, right? Replace the javascript editor with a silverlight one. Marvel at how it Just Works and how easy it is to extend over TinyMCE or FCK editor (or whatever that one is).
And if you've got MSDN on your machine already (ala Visual Studio), you can use the much nicer help application thingy instead of the some-what-broken-in-firefox online documentation.
Have you tested that code in IE6 yet? If not, you are in for a surprise.
Sure, you could chain the events, but that's ugly. DOM 2 Events already exists, so why not use it?
Dunno, but I'd imagine one reason might be to "standardize" the broken "body onload" event. For those who aren't up to speed in how crappy IE6 is... IE6 doesn't fire the body's OnLoad event when it uses a cached version of a document, it only fires when it loads a fresh one. Grrr....
Another reason I can think of is some of the libraries (YUI comes to mind) offer easy-ish ways of creating your own events. Having a (library specific) standard method to hook events that works with the (library specific) standard way of creating events might be nice.
Seriously, the bloom of incompatible javascript toolkits isn't making my life easy. I've standardized my own javascript code around Prototype (which is used in Lightbox). There are lots of cool jQuery-only and MooTools-only widgets I'd like to use, but I dont want to have clients pull down three javascript libraries for just one page.
And to finish my rant... just wait until your javascript toolkit vendor ships out a new version (prototype 1.6) that isn't completly compatible with it's old one (1.5). Just wait until 1/2 your widget set breaks on 1.6 and half breaks because of 1.6.
I love web development.
I've been playing with Silverlight. Took me a single night to cook up a file upload control that works on IE6,7,8, Firefox 2 & 3, Intel Mac & Windows (even 2000) and will work on any other platform Microsoft targets in the future. It just nestles itself right into my HTML all cute-like with no fuss. You can get your javascript code to interact with it just like a DOM object -- events and all. It is server-side agnostic and since it can serialize/deserialize JSON, it can talk with all the same server-side AJAX stuff my existing client-side javascript code does. In other words, it appears to be trivially easy to replace the javascript widgets with silverlight ones without touching a line of server-side code.
How long would it have taken to do the same file upload code in Javascript? Probably a week and a month of dealing with users running some spyware/toolbar that breaks the production code in insane ways.
Times are a changin!
load up an MTA
I'm in a library. Which MTA do I use when I cannot install software?
When I'm looking at several items, and want them sorted by popularity, I REALLY DON'T NEED to see an animated status bar show up to tell me that the page is being loaded.
But what if you wanted to sort in descending order instead of ascending order? With javascript your browser can sort the list instantly instead of making another request and waiting a few seconds for a reply.
Write an actual program that will merely communicate over the net
For which OS/hardware? How does it install on a locked down machine at the airport?
glorified Visual Basic apps
VB only runs on Windows. The redone version runs anywhere. You are an idiot.
You are a smart person. Web development, in it's current form, is probably the most needlessly difficult, frustrating line of development work you can do.
You are programing against a moving target that you have no control over. Worse, those target platforms can really suck and break in insane ways that you'd never catch because you simply cannot test on every target.
These "anti-flex" and "anti-silverlight" people are gonna get a wakeup call when none of their websites work in lynx anymore. Silverlight/Flex isn't for them, it is to keep us developers from going insane.