What caused Flash and Actionscript to become irrelevant? [closed] - javascript

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
At first glance this question may seem like I'm looking for opinions or a discussion, but hear me out. While I'm sure everyone has their own opinion of which tools are best to use, there have got to be some factual reasons why Flash's popularity faded away. I'm sure there were certain events and inventions that caused people to prefer other tools, and I'm dying to know what those events are. So I am looking for answers that are based on facts and events. All I can gather from the research I've done and the projects I've seen is that Flash used to be really popular for creating interactive media or cartoon-like movies, but now it's not.
The background story to this question is that over the past few months I've been creating a project with Adobe Animate and Actionscript for a college class. It's been fun and I find that Animate is extremely useful. I would like to think that the skills I've learned will be useful in the future, but I've heard from several different people that Flash is pretty much irrelevant now and I can't figure out why.
I know that front end developers are using Javascript and HTML/CSS for most things, and I do understand some of the advantages. Javascript programs seem to have more open-source availability, and of course no one wants to pay a subscription for Adobe products forever. But what I don't get is what replaced the visual aspect of the "stage". Something as simple as drawing a circle could become hard really quick, or tedious at the least, if you're just using code alone. And if you draw two or more objects, you have to worry about their relative positions. Flash makes that super simple by allowing you to just drag them to where they need to be. But once again I imagine it would be really boring to have to use trial and error to position things solely with code.
So are the Javascript coders using something similar to Flash for their animations that I'm just not aware of, or are they really just using code alone? If they are just using code, WHY would they give up the stage aspect of design?

Politics, sadly. Flash was/is superior to HTML5 in almost every way (explained below), but there were a number of non-technological factors that ushered in its demise. Below are a few that come to mind:
1) Ads. This was the way most people grew to recognize Flash content; if it was flashy and annoying, it was probably Flash. This was unfortunate as it was not the technology itself that was the problem, but the use of it. (the fact that Flash was used so much for this type of content says something about how effective Flash was at creating this type of content).
2) Full Flash websites/games. Again, this was not so much a problem with Flash, but those who used it to create the content. Often devs will produce content on machines that are significantly faster than the average user's, and do most, if not all, testing locally.
3) The 1st iPhone was quite slow compared to those that exist today, and it was slow compared to a majority of computers as well. It is no surprise then that a technology that specializes in multimedia, running in a virtual machine, may have problems running on such a device; however, to say this would be to say something negative about the device, and rather than do that a 100% of the blame was put on the technology. The average consumer's experience with my previous points made this tactic easy to pull off.
4) Adobe gave up after losing the PR battle. There were many things they could have done to save Flash, such as: not dropping Android support, not dropping Flex support, not dropping Flash Builder support, and not ignoring the dwindling Flash engineer community. There is no reason why the iPhone could not run Flash today (and run it well), and there is no reason why Adobe couldn't create a transcompiler to convert content; I already did this (flash api, full as3 language support, e4x, etc.), but it's not open source as of yet. If one engineer could do this, they certainly could have!
5) Overblown publicity of Flash vulnerabilities. Critical vulnerabilities are found in programs all the time, browsers, operating systems (yes, even OS X), etc. But due to the growing discontent for Flash in the general public, issues found in Flash were covered as if Flash was the only program that was exposing people to vulnerabilities.
Technology: Is/was Flash tech superior? Absolutely, HTML5 was actually a huge step back, and here is why:
1) Flash was stable. If you got your app to work, it would almost be guaranteed not only to function exactly the same in all browsers and operating systems, but also to look identical as well. Want to develop an HTML5 app? Either use a javascript library to fix all/most browser inconsistencies, or welcome yourself to a debugging nightmare. So, of course, you add that abstraction layer, but now what happens when you still have an issue? Well, now you have to dig through that layer..
2) Flash/AS3 does it better. Want to have pixel perfect text across all devices? Flash, yes. HTML5, nope. Want REAL classes, typing, Vectors, weak references, interfaces, objects as keys, namespaces, private variables, asset embedding, etc. ? Flash, yes. HTML5.. while it's possible to create a compile-to-JavaScript language to pull most of this off, now you have to deal with that output when you're debugging. How about complex, nested, animations? How easy/fast is that to do in Flash... Sure, editors can be made to output the equivalent in HTML5, but most will not stream like Flash did, and will have severe limitations compared to what Flash can do.
3) The Flash API. The Flash API was well documented, powerful, and pretty simple to use. Compare this to the joy of searching online looking at compatibility lists and vendor prefixes for HTML5.
4) todo... there is quite a bit more.
HTML5 is better only in the fact that it is 100% open (and it's not a plugin, which people tend to dislike). The SWF specification is open, and there was an open-source Flash player (the Tamarin project); so, it is not as if Flash was completely closed like some would suggest; personally, I would trade the openness of HTML5 for stability and consistency any day.
However, if openness is one's primary concern, then one would probably view the step backwards in capability and efficiency as worth it.
BTW: I actually write all my HTML5 and NodeJS code in Flash/AS3 and compile to HTML5/JS. I can still use Flash for debugging (and as my gold standard if you will), which is fantastic..

Related

HTML5 Boilerplate vs. HTML5 Reset [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Hey everyone — HTML5 Boilerplate and HTML5 Reset are two HTML, CSS, and JavaScript templates with a lot of modern best practices built-in. Their goals are largely the same:
Fast, robust, modern Web development
HTML5 (duh!)
Cross-browser normalization (including support for IE6 and mobile browsers)
Progressive enhancement and graceful degradation
Performance optimizations
Not a framework, but the starting point for your next project
Obviously, they're very similar in function. In what ways are their implementations different (for example, perhaps IE-specific CSS fixes are achieved using different techniques)? Are they at all different in scope? It seems like HTML5 Boilerplate is a bit larger (build tools, server configuration, etc.), but it's hard to know where it goes beyond HTML5 Reset when it comes to the actual site that people will see.
In general, both projects set out to provide a solid starting point for developers working on web projects. They both get rid of a lot of the tedious, some-what error-prone boilerplate that many developers find themselves re-creating for each project. The details in how they go about it are slightly different, but for the most part, they achieve the same results.
HTML5Boilerplate has, as you noted, added in some build-script pieces to help developers follow best practices to speed up their pages in terms of server-side items, such as far-future expires headers, etc. where-as the HTML5Reset project is more focused on the semantics, content, and styling. For example, HTML5Reset has more example structure for the content of the page in HTML5 (to help show people how to use some of the new elements), whereas HTML5Boilerplate does not.
The response-time and page speed parts that HTML5Boilerplate includes get more and more important as more users find themselves on mobile platforms, and as Google increases the effect page response times have on page rank. There are lots of papers that show a small increase in the page response time has a measurable negative impact on how your site is used and perceived (especially in an eCommerce setting...often a 100ms slower page will get percentage less things sold).
On the CSS front, the majority of the reset style section for both projects is very much the same, with some minor differences in what the baseline is set to. The IE specific fixes, however, are largely the same, with HTML5Boilerplate asserting a bit more control than HTML5Reset over how IE styles some things like form elements (ie. check box / radio buttons and valid / invalid states)
Two major CSS areas that HTML5Boilerplate covers that HTML5Reset does not are common helper classes to assist with making sites more accessible, such as .hidden and .visuallyhidden, as well as some substantial adjustments to the print styles that serve to both make printing more similar across browsers, as well as some cost-savings and accessibility things like making background images transparent (to not waste toner), and adding the actual URL to links and the title to abbreviations.
I would highly suggest reading through both projects' info and how they do things in a side-by-side comparison because the similarities, and also the differences (and the reasoning behind them) is quite informative and has helped me to better decide what parts of each I wanted to use.
Ultimately, just like any "library" sort of project, you as the developer need to understand what you are doing and probably should tweak your baseline to meet the particular needs of the project.
You can use either one...
Like #murtaugh said (http://5by5.tv/bigwebshow/45) you don't need to learn anything when u first start with Reset. In my experience, working in an R&D department, when you need to demo or do quick iterations you can use the Reset (or Boiler if u already know it). When I need to build the product for deployment I turn to Boiler just because has more stuff.
Works for me but now because I know both I can easily use either one.
I actually almost want to say using the traditional reset.css is the best... I find no problems with compatibility in my mobile apps. However, I am developing these apps using the jQuery mobile framework.
So I guess it's really conditional as to what kind of tools you are using. Phonegap doesn't seem to have any problems compiling my code into all OS. And viewing my source code in emulators looks perfectly fine...
So I really don't see the point of a boilerplate unless you are trying to achieve polyfills.
I work in an environment where previous developers roped the company into using both JQuery and Prototype...and it's a mess. Not only do we have to work out of compatibility mode, but just think of the extra overhead that it causes. When debugging, Prototype "hijacks" debug messages in Firebug, which leads to even more work. And the maddening part is that I've been undoing this mess for months and am just starting to get close to being done with it....and just when I'm about to pull the plug on Prototype I always seem to find another section that relies on it...
It's for this reason that I argue every time against combinations of frameworks that have similar purposes. For example, no matter how cool you might think YUI Grids is, if you load the entire YUI Framework you best not be doing Jquery, Moo, or Prototype. You'd be just needlessly bogging yourself down. It kills the load time (which wrecks the user experience) and just gives developers headaches and needless work.
Look at this phase of your site like building the foundation. You have the opportunity to use anything you want to use, but you have to be careful not to "paint yourself into a corner" so to speak. So, use purpose-built and best in class tools that are available based on your resources. Don't just use something to be cute! We're lucky in that many very high quality tools are free, so we have a choice. But know that you're steering the direction of your site for the future, and you might be the person like me who has to deal with the consequences if your decisions are hastily made.
So, unless you're NEVER going to use another framework, I endorse Reset...or even just doing top quality standards compliant CSS.

Should we consider Flash as a last resort? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
When we make a website with some interactivity (not whole flash site). should we always find a way JavaScript way before to use Flash? Should we consider Flash a last resort, if possible?
It is true Flash will not be indexed by Search engine. and it will not run on apple devices.
Will javascript also perform better than flash, in terms of speed?
Edit:
And how to know , the effect which we want to achieve and possible in Flash , can be possible in javascript?
Flash has it's advantages. I personally love JavaScript and are always surprised what is possible without Flash. But on todays browsers you can do a lot more with Flash and it ill perform a lot faster.
In the bright future, you might be able to do almost everything you can do with Flash using JavaScript and the canvas element. But until the majority of all browsers will support that, there are some things you can only do with Flash.
I don't use flash on any of my projects anymore and I also have a lot of fance stuff on them. But I also have a fallback for non-JS users and you should also have that for non-Flash users. and because a JavaScript application/widget is build using HTML and CSS, such a fallback is much easier to realize than doing it with flash.
I don't say, that you should not use flash at all, but you should make yourself a list of things you want to have on your website and than search for JavaScript libraries or plugins that can do that.
Isn't anyone bored with this question yet? There are tons of answers/non answers on the internet. One could write a book about Flash advantages & disadvantages, actually many books :) I personally don't think there's a rule you can apply to every project that will let you know if you should or shouldn't use Flash. This is a personal choice , based on the type of project you're dealing with , the languages you're comfortable with and the objective you're trying to achieve.
Some clients won't care about not being able to be accessible on Ipads, some others will. You don't tackle a business site the way you would tackle an artist portfolio. Keep your options opened and , more to the point, master as many languages as you can and when you do, I have no doubt you won't bother with this question again.
so:
should we always find a JavaScript way before to use Flash?
why not? if JS can do it with similar quality & performance, why go Flash?
It is true Flash will not be indexed by Search engine.
Google has made a lot of progress in indexing Flash content so it's not entirely true
and it will not run on apple devices.
False. It will run on most apple devices, of course not the Ipad!
Will javascript also perform better than flash, in terms of speed?
that would depend on what you're trying to do
And how to know , the effect which we want to achieve and possible in Flash , can be possible in javascript?
Some level of understanding of both languages would help
I'd say no, but then again I might be bias.
Flash is good for its own certain points and needs. I think that it has received bad press as it has been misused a lot, it is not a replacement to other languages but has been used that way for quite a while. It should be used when needed, rather than an instant fix to make things look "cool" or "modern".
Flash is good for application based design, multimedia and complex animations. This admittedly is rather fuzzy, but it's hard to define nowadays closer than that. Javascript on the whole is a very powerful tool, and the new HTML <canvas> tags allow a great flexibility on what can be accomplished with JS, CSS and HTML, but requires specific support that isn't guaranteed on all browsers (10% of people still use IE6 supposedly) so it's very much a gamble on who your target market is to what you should be doing.
On the whole if you know what you are doing it is possible to do nearly all that flash does in javascript/css/back end technologies, but it is less encapsulated than a flash example, and as far as I know flash is more efficient in its resource allocation and can take advantage of CPU enhancement, where javascript can't as of yet. It all depends on specifically what you are trying to put together and how complex/portable you want the code to be. If you are putting together a 3d shooter, use flash, if you are trying to move a <div> 5 pix to the right, use javascript.
Flash in itself will run on "apple devices" except for the iPhone and offshoots of this technology (iPad for example) but will still run in safari etc. on macs. and is constantly getting better at being indexed on search browsers, and there are get-arounds for that anyway, so that shouldn't be the reason for stopping you.
Have a look at jquery examples like this page to see some of the fun things you can do, and maybe some inspiration.

Can I use JavaScript to do the same what Adobe Flash does?

Is JavaScript capable of doing the same what Flash does? And if it is the case, can it be a good idea to switch from Adobe Flash to JavaScript?
No, JavaScript cannot do what Flash does.
Maybe HTML5 w/ canvas,JavaScript w/ JQuery,CSS3, some Webkits and some SVG/JPG to handle pictures and animations can make an attempt at what Flash was 5-10 years ago.
Video
JavaScript - There is only one implementation I know that slice the video into JPEGs then dram it onto the canvas. No clue what happens if one wanted to stream a file.
<video> tag - Best thing to come along. I would not lie. But this is not JavaScript.
Audio
JavaScript - I remember once it could be used for MIDI files but then it needed compatibility checks based on the browser
<audio> tag - Same reasoning as <video> tag, it is not JavaScript
Animation
These are three places I know making the cream of the crop that can be made with JavaScript.
Mr.Doob's Playground
Spiderman Animation
SmokeScreen Flash to JavaScript
Note well.
Do not talk about Apple Demos ... that is a joke and all marketing. They have only optimized for their browser (Safari)
Also do not talk about what Steve did or did not say. He is a pro at marketing. The other steve (Steve Wozniak) is the engineer.
(1) I highly respect because Mr.Doob really pushed that <canvas> and JS . (2) Was great animation that could be accomplished by a teenager in Flash IDE 5 years ago ... way too much effort to make something so simple. (3) Is really good yet you start with the Flash File ^.^
Lines Of Code
In many cases ActionScript, better yet the Flash IDE make animation a breeze with half the lines of codes (or maybe even simple drag and drop on timelines) than JavaScript. Libraries such as JQuery were brought in to try to shorten the amount of code. Even then in most cases less code/implementation was needed in ActionScript.
Accessibility and Performance
This is in the hands of the developer and has nothing to do with the language. Flash is capable of providing deep linking with SWFAddress (Ajax), page resizing (Stage Scale) and so forth. People constantly talk about performance with Flash, yes this is true but this is poor design on the developer for memory management.
Updates
JavaScript will be limited by the <canvas> and other elements to achieve what Flash can do.How ? If issues started to occur in HTML5, what would you do ? Send in a bug request ? No ... you will wait a next 3-5 years for HTML6 specification.
Suggestion
I suggest looking through Mr.Doob's work, Webby Awards and google the best of Flash Websites. Look at them carefully see if you can bring up case studies. Like this one : Creating marketing platforms with Adobe Flex Website under study : http://www.bombaysapphire.com/
And a word to a wise , one of your favorite websites - YouTube, would not have survived if it was not for Flash :D
Hell you can use javascript to "do" flash!! Check this out! Smokescreen
On a serious note, flash has its own advantages. Like e.g. games and some very specialized apps like audio video editing etc. Maybe javascript and HTML5 is not there yet, but its getting close!
Is JavaScript capable of doing the same what Flash does?
No, definitely not. While both share some capabilities, like animations and interactive interfaces, JavaScript's and Flash's design philosophies differ fundamentally, and in terms of features in those fields, Flash is certainly way, way ahead.
And if it is the case, can it be a good idea to switch from Adobe Flash to JavaScript?
It might, depending on what exactly you are doing in Flash. If you outline that in more detail, you will certainly get more concrete answers.
Here's a response to Apple's recent trumpeting of HTML5 - Jump back in time with HTML5. There's still plenty of reasons to use Flash!
The Apple HTML5 demos (left parts)
only work with Safari (4.7% of all
users on all devices). Some HTML5
features work, others won't work on
other browsers. As a matter of fact,
HTML5 is not really a standard at all.
The Flash TODAY demos (right parts)
show how 97% of all websurfers can
experience Flash the way it is
supposed to be today & tomorrow: fresh
& innovative. By the way, these
Flash-examples are extremely hard or
simply impossible to build with
HTML5
Depends on what functionality you are looking for. While javascript has much evolved recently and many frameworks were introduced it cannot be compared to Flash in terms of creating rich web interfaces. I think though that progressively new concepts will be introduced like HTML5, usage of the GPU and HTML + javascript might one day fill the gap.
Javascript is vast. But it cannot replace Flash.! The biggest Advantage of using flash is hiding the source code.. Which in Javascript is nt applicable always.!
Flash is Used in Animation of Cartoons and 3D web sites etc.. Of course u cannot create a front end competing to Flash..
One good solution would be => If you want ur site to hav good programming properties den go for javascript..
If U want ur site to be good in Front end design den go for Flash!!
Although flash has its scripting language [Actionscript] its not dat much flexible as javascript!!!!

Do we still need backup code for people who have javascript disabled? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I hear about it a bit in tutorials that I watch, that certain things won't work if javascript is disabled. Occasionally I see workarounds.
The question is, are these relevent? I can't imagine anyone not having a javascript enabled browser nowadays, except the most ancient of phones, and chances are your page won't render on them properly anyway.
Do people still bother to write backup code for javascript being disabled?
Edit: As a test, I turned javascript off. Facebook doesn't work.
Edit: I understand about visually impaired users, but do people care (harsh, yes) if their experience is buggy? Not to sound disrespectful, but not sticking to strict standards will alienate people using Internet Explorer 4 and 5 too, but we don't seem to care about them...?
Edit: Saying that people should do it seems like a very automatic response, considering how many people use JQuery and other groovy addon libraries.
Edit: I tried a bunch of fortune 500 sites, and so far about 70% of the ones I tried have broken
Dell
Walmart
Fedex
Intel
Coca Cola
Yes, we still need backup code for people who have JavaScript disabled.
JavaScript is often used to do things that break in screen readers (so many screen reader users disable it) or to cause changes to appear out of sight of a screen magnifier.
JavaScript is still one of the biggest attack vectors to exploit security holes in browsers.
Add-ons such as No-Script are increasing in popularity.
Search engines tend not to execute it (so you don't want to hide your content behind it)
I prefer to think of it as a foundation rather than backup.
I understand about visually impaired users, but do people care (harsh, yes) if their experience is buggy?
Nasty people don't.
The law (in many jurisdictions) does.
Not to sound disrespectful, but not sticking to strict standards will alienate people using Internet Explorer 4 and 5 too, but we don't seem to care about them...?
IE 4/5 have:
a smaller market share than users without JS
many security holes
no support from their own publisher
As a developer I no longer worry about 1% of users who turn off Javascript. It is too time consuming and development time is too expensive to waste on such nonsense. AJAX saves an incredible amount of bandwidth which turns directly into $$$ savings, which makes profits higher. If I lose one or two potential users of the site for every 100 users, those one or two lost users will cost a lot more in development than the potential income of they could ever bring in.
Try turning off Javascript and logging into Facebook, it becomes a very broken website after that. If it's good enough for Facebook, its good enough for me.
Support for JavaScript-disabled web sites a nice thought, but not of much help, and of questionable value, IMHO
It is almost impossible to design a robust website without java script, and those that disable JS, for whatever reason, probably don't expect much of a user experience. So if you are coding for that 1% of the population, you have no choice. But for the majority of us, it is a given that JS is there. Accessibility is a different issue, with its own challenges. When I was doing web sites for Hewlett-Packard, they had to meet strict accessibility standards, and it was tough to create anything more than very basic web pages. I wouldn't wish that on anybody.
I have a different opinion to many here. I don't think you necessarily should care in some scenarios, especially if your website is targeting a particular group of people or that it is going to mean a lot of work.
if you refer to:
http://visualrevenue.com/blog/2007/08/eu-and-us-javascript-disabled-index.html
(source: visualrevenue.com)
You can see that year on year more browsers than ever have Javascript enabled, contrary to the other answers' claims. It was at 96.9% in 2007.
So you lose 3% of potential viewers, so what, your advertising campaign will do a lot more damage than that!
Yes. Especially when it comes to 508 and WCAG compliance. While the technologies to create accessible JavaScript are coming out of their infancy (see ARIA), developer's should still be coding sites in a way the does not require JavaScript.
http://www.w3.org/WAI/aria/faq
http://www.w3.org/TR/WCAG10/
All the other questions got most of the points covered, but I'll chime in with this: it's not a big deal to have your page(s) degrade gracefully in the absence of javascript. If you've got some super-whizzy ajax-infested real-time comet style app that really isn't going to work without javascript, you should at least render a nice message to the effect that javascript is required.
It depends on your audience and type of website.
For instance, a graphic artist portfolio will not be visited by blind people or people using text browsers. So in that case it's not so important to build nice degradable JS, expecially because it will most probably be used for graphic effects.
If, on the other hand you're developing a news website and you decide (for whatever reason) to dynamically load your news with JS then you should definitely make it degradable. Also, remember that the spiders of indexing engines may have difficulties in indexing content loaded with JS in your page.
At the end of the day, in most cases it's not so difficult to program the site so that it works without JS. If you're retrieving content dynamically you already have the server-side code to load the content, you just need to accomodate how the page is called.
Same thing for forms, you can send the content via AJAX or via a normal POST, the backend will be pretty much the same, so it's again easy to implement.
Of course, the problem is not even posed for JS code that is purely graphical.
My recent experience:
My former supervisor claimed, in earnest, that because Google Analytics told us that "87% of our users have Java enabled and less than 3% are using IE6," that we didn't have to worry about supporting older browsers or users with JavaScript disabled.
Problem 1: Java is not JavaScript.
Problem 2: In order for Google Analytics to track a hit, the browser must have JavaScript enabled because the GA interface is a JS include. GA is not, and can not, be aware of users with JS disabled, which can potentially severely skew its reports.
Problem 3: one of our biggest customers requires that all engineers use IE6 with JS disabled.
Problem 4: The boss (at the time) didn't know how to read analytics reports.
If you want to know how important this support is to your business, a good place to start is the IIS logs. Just about everything related to the browser caps is stored by IIS. I regularly import the logs into SQL Server and run some basic reports from my admin site, which come in handy every time someone starts suggesting that we go crazy with the jQuery BS.
If you decide to start building complicated, script-dependent interfaces, be sure that your interface degrades gracefully and doesn't remove required functionality if JS is disabled.
It is not merely a question of whether a browser is capable of executing javascript, but if a user has disabled it for some reason.
For example, you need to be aware of vison-impaired users. Such users might disable javascript, because the effects are confusing their screen reader software.

What's going to replace HTML & CSS & JS? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
HTML and CSS are showing their age.
SASS generates CSS (because CSS isn't clean enough). Graphic Designers don't work in HTML, they work in graphics tools then have to translate it to HTML/CSS. JavaScript has to have abstractions like jQuery, and CSS has a bunch of hacks to even start approaching consistent predictable user experience.
It feels like people are doing some wonderful things despite the technologies, not because of them.
Surely there is a better way?!? Something more closely aligned with the task at hand.. of providing a fluid intuitive (consistent) user experience to let users achieve their goals.
Thoughts?
Nothing, I believe they are here to stay for next 10 years.
The Internet experience might be enhanced by technologies like Flash & Silverlight but what's valuable about Internet is not the technology but the information.
Therefore, breaking Internet compatibility for pure technological enhancement will never work.
BLTML: Bacon, Lettuce and Tomato Markup Language.
In the future, the web with only be used for posting tasty things we want to eat, so it makes sense to develop a language geared just for this.
The pictures of kittens with words on them will likely be supported with a gross hack .
Graphic Designers don't work in HTML
DTP designers don't produce paper and ink either. Design something and produce something, these are separable tasks - when you have an idea for a tv spot you still need lots of technology between your creativeness and the result, the same applies for the web.
Javascript has to have abstractions
like JQuery, and CSS has a bunch of
hacks to even start approaching
consistent predictable user
experience.
Oh man, js doesn't has to have, developers simply like to make their job easier, this rule applies to various programming languages, it's like saying python has to have django. Frameworks and libraries are over the language, they are not a must.
CSS 'has a bunch of hacks' because some browser producers don't give a damn about something called "standards", not because the language is badly designed.
Surely there is a better way?!?
Something more closely aligned with
the task at hand.. of providing a
fluid intuitive (consistent) user
experience to let users achieve their
goals.
What user experience is not provided with html,css,js? I really don't get your point, and what you expect from the Web.
Oh, and if you are like 'you know, you need flash for something or whatever', start getting interested in canvas.
HTML and CSS are here to stay for a long time yet!
While they may not be as intuitive to use for designers as say PhotoShop, well formed HTML is machine readable - this means that it can be used by humans AND computers. This is very important and useful. Imagine a web full of pictures that look beautiful but cannot be crawled or searched by Google?
HTML and CSS are superior because of the structured information that underlines them.
I don't think that HTML and CSS are showing their age, I think that browsers are showing their age. I like being able to describe what I want done, but not HOW to do it.
I guess what I want is browser vendors to use one rendering engine, or if nothing else, a SSL-type of certification for browsers. Kind of a global impartial body that's measures browsers on a quality bar-like scale.
Just like with SSL certification, it's done by a third party. I'm not sure what the pricing structure would be but I don't think you should have to pay for it. I think that it would make a great "works in this browser" logo like the Spam Free and Mal-ware Free logos we've seen popping up on sites over the years. Or perhaps an Acid1, Acid2, Acid3 passed logos for browsers.
I would argue that libraries like JQuery and Prototype exist because browsers all have their quirks. We just got tired of writing all that handling code, so some very smart people did this for us.
Personally I think HTML and CSS are very elegant, and while the W3C certainly isn't hasty, I think it's probably fair to say that a certain browser has been holding back design on the web more than the technologies themselves.
CSS3 has support for fantastic things such as web fonts with #fontface. Javascript engines are becoming increasingly speedy and allowing for things like John Resig's processing port which would have been unimaginable years ago.
We need to see users adopting new browsers at a faster pace, and we need to see vendors getting behind efforts to encourage their users to upgrade.
I think it's a mistake to think that abstractions are a negative thing, and indicate some problem with the base technology - technologies naturally evolve through abstraction. There's some inconsistency in your post in the sense that you decry the need for abstraction, but then mention that you desire consistency - that consistency across clients is achieved through abstraction. I no longer have to worry about how different clients handle the DOM - jquery does this for me. CSS hacks by the same token aren't really necessary, and it's quite acceptable to serve a different stylesheet to that browser; the rendering difference between the other mainstream engines are pretty minimal.
Please also consider that we're still using a lot of "old" technologies (Unix, c, c++ to name a few), because they are functional, elegant and well designed.
Worse is better. HTML and CSS are never going away because of the large volume of content that's written against that platform. Same thing with C. It's a terrible language, but it will always be with us because nearly all software is written in either C or C++.
A huge volume of JAVA means that's never going away. There's still a market for COBOL programmers.
It's a popular idea among some programmers to get really frustrated at a crufty system like HTML/CSS/JS, and think "Hay, let's demolish it and start over". Well you know, I could invent my own phone that is 100 times better, and with better sound quality than any other phone. That's the easy part. The hard part is having someone to call.
Like it or not, HTML/CSS/JS is the technology trio that became popular, and that means millions of people have invested trillions of dollars in producing content for the technology. Millions of people will be quite reluctant to throw that effort away because someone says HTML/CSS/JS sucks.
It's a mysterious thing figuring out what technology is going to become popular. It's not something you can control for the benefit of your own comfort. But at least, you know, there's such lovely computer science concepts as "abstraction", which if you can master it, will be your secret weapon. Jquery is an example, but it can be taken very much further.
The problem would not be to design something to replace HTML/CSS/JS, but to get browser vendors to adopt it. Good luck with that.
As central as the web experience and HTML are in my life and in your life, the only computer most people in the world use is their phone. The web just doesn't work well even on a multitouch touchscreen.
Just like you no longer enter your game using the ROM basic before playing it, and you no longer see text only screens around (well mostly), some day the web is going to be consumed by specialized devices or by specialized applications for your phone. Machine readable web, or in other words, web services. You can call that web 3.0 if you like.
I believe that the problem is not HTML, CSS and JS or their age (they are constantly evolving anyway). Theoretically you should be able to create one version of something and have it work exactly the same across different platforms. Which is where the problem lies: the platforms.
Saying those technologies are old and therefore need replacing is like saying C++ is old and therefore should not be used for game development. They are actually very appropriate and powerful tools for what they were designed for. Therefore I would predict that its not the HTML, CSS and JS that need to or will be replaced, but that the current platforms need to get their shit together (some more than others) and follow the bloody standards!
That said, they do need to keep evolving to stay relevant.
I think XML with XSL is the future. Graphical designer tools would come with their own XSL stylesheets, tailored to the strengths of the tool, and the tool would generate XML files that use the stylesheets.
But I'm no clairvoyant; what's going to be hot in the next 5 years, who knows. :-P
If you listen to Microsoft, Silverlight will feature prominently in the new web. Since it uses XAML, which is just a text file, it has the potential to be search engine friendly.
Others like Flash.
Of course I am sure that something else new will be invented in the future....
I think RIA's like Adobe flex/air/apollo and Silverlight etc will eat into some of the html market share , but not totally replace it.
Some of the issues that plagued RIA's like SEO related stuff, lack of back button support are being resolved.
The good thing with RIA's is that it is browser independent (as long as the user has the right plugin) , I could foresee future browsers launching with RIA support built-in thereby ensuring a 100% market penetration for apps built using them.
For documents and usual web pages, HTML and CSS are there to stay and evolve (Sass is nice indeed).
For applications, mobile code (javascript most probably) driving canvas-like graphics will help merge web apps and internet-enabled desktop applications.
— I wonder how ridiculous these predictions will look like in 10 years :)

Categories

Resources