Aaand that's where I stopped reading. Try not to kick your articles off with dogmatic statements like this and, if you have to, at least make sure they're factual.
Aaand that's where I stopped reading. Try not to kick your articles off with dogmatic statements like this and, if you have to, at least make sure they're factual.
In this case the background image adds absolutely nothing to the user experience or conveys what the content is about, if anything its quite an example of bad design and interferes with the user for no good reason! The "web developer" has added it just because he could not because there is any good and thought out reason to use this "image page monstrocity"
This is my personal website. I also use it to showcase my photographs. I agree that they don't add anything to the content.
Its just funny seeing same mistakes being repeated and various "trends" employed by web developers for no good reason other than "because we can, and it looks cool", but thats ok for personal projects since you are exploring what can be done.
As stated below, I will probably remove this Introduction, since it seems to distract from what this article is about. I hope you consider reading the article anyway.
"Google is changing the monopoly of JavaScript by implementing the Dart VM in their own browser."
As far as I know community doesn't care much about Dart [1] and they are concentrating on further enhancement on ECMAScript.
[1] : http://en.wikipedia.org/wiki/Dart_%28programming_language%29...
http://news.dartlang.org/2013/12/ecma-forms-tc52-for-dart-st...
You can take a look at :
http://www.infoworld.com/article/2608454/web-development/goo...
https://en.wikipedia.org/wiki/Dart_%28programming_language%2...
Do you _honestly_ believe Dart is going to replace or threaten Javascript "very soon"? Enough to be willing to bet on that?
JS is the common compilation target of the web, and also happens to be a language that many programmers find tolerable enough to use directly.
As nice as it is to have multiple options of source languages for the web, there's a lot less value in having multiple options for compilation targets, as well as greater costs (particularly given how tied execution engines are to browser engines, so that you really need a separate engine for each compilation target for each browser engine. Having a reliable, good-enough cross-browser target language that is a the intersection of the JS supported by each browser engine is easier than doing that same thing for multiple different target languages.
A new target language is going to have to offer really compelling improvements in execution to make sense to compete with JS in that role on the web.
Deleted comment
EDIT: OK, I see, he misspelled it...