“Everyone seems to have a replacement for JavaScript – Google even has two. Now Microsoft has revealed that Anders Hejlsberg has been working on a replacement and it has released a preview of TypeScript. TypeScript is open source – Apache 2.0 license – and a superset of JavaScript. As you would expect from a Hejlsberg language it incorporates type checking, interfaces and lots of syntactic sugar.”
TypeScript and Dart try to solve the same problems…
… something smells like NIH here.
PS. I know they market it as statically typed, but it is in reality optionally typed, just like Dart. At least Google is admitting that, whereas MS is all about marketing … again.
They solve the same problem in different ways. Typescript is closer to ECMAScript6 and a superset of JavaScript.
Also: The correct term is statically weak typed language. There are holes in the type system, but there are compile time guarantees if you stay within the sandbox.
So technically, yes, sorry, the creator of C# knows his terminology.
FAIL
That is why _his_ slides and the website now say:
Optional Static Types
The point is, you can say static typing without implicitly saying strong typing. You’re splitting hair and claiming some grand marketing conspiracy. Please.
To suggest the creator of C# is purposely misleading is preposterous.
As far as I can tell, the is no universal agreement on the definitions of strong or weak typing, and even if there were, the extent to which type annotations are mandatory or optional is irrelevant.
In my view, a weakly-typed language must support implicit type coercion at least to some extent. C is a weakly-typed language which will, for example, happily add an integer to the ascii representation of a character. Python is an example of a strongly-typed language which will complain loudly if you attempt the same. But you’ll never find type annotations in Python.
Languages like JavaScript and PHP go to much greater lengths to use implicit type coercion to avoid type errors, with occasionally hilarious results. JS isn’t a weakly-type language because it doesn’t require type annotations. It’s a weakly-typed language because, for example, [] + [] == ”;
butters,
“In my view, a weakly-typed language must support implicit type coercion at least to some extent. C is a weakly-typed language which will, for example, happily add an integer to the ascii representation of a character. Python is an example of a strongly-typed language which will complain loudly if you attempt the same. But you’ll never find type annotations in Python.”
In my opinion, C doesn’t have a “character type” (like a pascal CHAR). The ‘char’ is actually an integer type in C, which in most (all?) implementations happens to be an 8 bit byte. Because C doesn’t have a string type either, we’ve become accustomed to representing strings as array of bytes (char). But that doesn’t make the ‘vector of chars’ nominally equivalent to a ‘string’, they are different concepts.
If you follow my reasoning, then you wouldn’t say C has a construct for “add an integer to the ascii representation of a character”. If we renamed C’s ‘char’ type to ‘byte’, you would have recognised the type for what it is (an integer instead of a character type, which C doesn’t have).
Edit: If C did have a character type, I assume it wouldn’t support direct arithmetic without a cast. Pascal doesn’t support character arithmatic. .net doesn’t. Javascript, which unifies characters and strings, doesn’t. PHP does it’s own thing by re-interpreting the character as a ascii digit.
Edited 2012-10-02 15:20 UTC
A ‘char’ and ‘unsigned char’ are typically 8-bits; however, they are by definition the smallest integral unit on the system – whether it is 1, 7, 8, 15, 64, or 128 bits.
A one point 7 bits was very typical hence ASCII is officially a 7-bit character to integer mapping, while ASCIIZ is an 8-bit mapping, and projects like Qt only rely on the 7-bit mapping.
Today, 8-bit is the norm and we haven’t gone above that since having an 8-bit integral type is quite useful. However there is nothing keeping anyone from making a 16/32 bit char/byte computer – which would simply mean that UTF-16/32 would be the standard and ASCII wouldn’t be very easily supported as you would have to mask-out a good number of the bits to get the data.
TemporalBeing,
“A ‘char’ and ‘unsigned char’ are typically 8-bits; however, they are by definition the smallest integral unit on the system – whether it is 1, 7, 8, 15, 64, or 128 bits.”
Agreed.
But if the smallest integral unit on the system wasn’t exactly an 8 bit byte, then we’d start having numerous compatibility issues such as how to implement stdint.h. Lots of code would still work if registers were just padded with more bits, but packed structures would be incompatible, which I believe is why POSIX mandates an 8 bit char.
http://stackoverflow.com/questions/6631491/why-did-posix-mandate-ch…
Of course, this doesn’t rule out the existence of micro processors that only support a fixed word size > 8 bits, but they might have trouble parsing 8bit aligned structures which come in over the wire, etc.
Edited 2012-10-02 17:18 UTC
Agreed.
I have a digital camera at work that doesn’t do byte alignment. All it means is you have to be careful how you build the structure so you can overcome its inabilities to pack to the byte. (I think its compiler only does 2 or 4 byte alignment; so no pack(1).)
No, MS admits that JavaScript for server site is not an easy task to maintain, Dart is a different languaje from javascript, TypeScript is a superset of javascript (just like c++ is a superset of c), with means, that Javascript is 100% compatible with TypeScript, and adds static typing and many features javascript doesn’t have. Besides TypeScripts compiles everything to JavaScript, just like CoffeScript does.
I like the solution, because it comes with the Apache license and is a very well thought.
I’d like for once that these haters read the documentation and statements before making such ignorant comments.
Except C++ is not a strict superset of C, which means that C is not 100% compatible with C++. I.e. there are C programs which either are not C++ programs, or have a different meaning in C++.
I hope TypeScript does a better job at being a superset. But then, if you’re 100% compatible with JS you get all the crazy stuff like this: https://www.destroyallsoftware.com/talks/wat
In many cases the C’s weak type system does implicit conversion, while C++ requires an explicit cast due to a stronger type system.
The ?: has a different priority order due to grammar issues.
Finally, after C89 and C++98 each standard group went its own way.
<p>Does anybody know how this looks as far as security? And please no “Its from M$ so its worthless” as I really want to know. the biggest complaint I’ve had about JavaScript is that frankly its a security nightmare, you block JavaScript and malware drops right off the map.</p>
So I honestly don’t care if it comes from MSFT, Google, or Toys R Us, if it helps to get rid of the security nightmare that is modern JavaScript I’m ALL for it.
The security issues have more to do with the DOM and other scriptable client resources. It’s up to these interfaces to ensure that they do not expose unsafe operations. JavaScript simply allows applications to use the provided interfaces. In the scheme of things, Flash and Java plugins have been at least as problematic for web client security.
What are the benefits/drawbacks of TypeScript over CoffeeScript then? I agree TypeScript and CoffeeScript are much closer to each other than either are to Dart.
CoffeeScript is syntactic sugar for JavaScript. TypeScript is optional static type checking for JavaScript. Dart is optional static type checking plus various incompatible semantic cleanups and a standard module system for JavaScript.
TypeScript is definitely closer to Dart than CoffeeScript, but it doesn’t go so far as to break JavaScript compatibility like Dart does. CoffeeScript-like syntactic sugar could be implemented as a pre-compiler for either language. LawnDart, if you will.
Takes a whole LOT of arrogance (and/or ignorance) to accuse Anders Hejlsberg of being an empty suit.
Yeah, he’s more of a hired gun than an empty suit. I really do admire him and his skills. The issues I have with .Net are not his fault, but the things I admire about C#/.Net are his doing.
I’ve heard somewhere that the problem with making web apps isn’t with JavaScript but with the DOM. Does this new super-set of JavaScript do anything about the DOM or is it just more stuff dealing with the language?
If not I think someone should get cracking on a DOM replacement instead of all these new languages. Also if this is really EcmaScript 6.0 or something why not call it that instead?
The DOM is partly fixed with HTML5.
… and it is even better with jQuery. It becomes so intuitive, I almost forget how we worked before such libraries.
The DOM issues are mostly browser specific problems.
You still have to battle beast of Redmond on a daily basis if you have to serve the public at large though.
Nice giant swaths of missing features…
http://www.findmebyip.com/litmus/
Especially the extremely useful CSS3 stuff.
But worse is its random bugs with canvas… yuck..
And with the latest version of IE for XP being IE8… Talk about random bugs… IE8 is the new IE6.
Thank god we don’t have to deal with IE6 or IE7 as much anymore… IE7 was God’s punishment for me complaining about IE6 for so long 😀
Somewhat related: if you want to make the world a better place for all us web-developers, spread the word that people stuck on IE7 or IE6 can install Chrome Frame without admin rights on their machines!
YAY: http://www.google.com/chromeframe
It won’t break anything because it’s only triggered if the website they visit specifically tells it to be enabled.
Maybe HTML5 will bring about world peace in another 5 years
There is nothing wrong with IE8. Until Firefox 3.0 (I think) it was doing a better job of being Standards compliant.
Also what nobody mentions is that if you add an XML element to an XHTML document, every browser except IE will happily ignore that whether or not the namespace is declared at the top of the document or not, and render it even though it is invalid XML.
There is a lot of stuff IE gets wrong, but other browsers do lots of shitty things as well (until I think Chrome 12 or 13, if you were rendering a legend tag with display:block, it wouldn’t render correctly unless you added a padding to the fieldset).
As for the missing CSS 3.0 features most of these weren’t actually finalised or proposed by the time IE9 was beta. Chrome and Firefox have a very different release schedule than Internet Explorer and why there is always a discrepancy in features.
Even simple things like zebra striping in IE8 don’t work (via nth-child, or any :nth selectors), selection::, :not, border-radius, TONS of css issues when styling tables (tbody scrolling took so long to only barely work in ie
), opacity issues (have to use the IE filters hacks).
Though IE8 is miles ahead of IE7. In IE8, it usually just doesn’t support the feature, in IE7 and IE6, it would botch it terribly instead of letting you gracefully fallback. I can live with having to support IE 8 for a while longer. In the corporate world it’ll be common for a while since it’s the last IE browser for XP
(that’s what I meant by “the new IE6″… it’s here for a while)
My biggest issue is knowing that when IE6 became the dominant browser by default (was good enough at the time and Netscape faded and Mozilla was being crazy), MS completely disbanded the IE team and basically held back web development for years with the monstrosity that became so entrenched.
Never again.
Edited 2012-10-02 06:47 UTC
IE 8 doesn’t support CSS 3, it supports CSS 2.1. There are plenty of polyfills that are already available.
Yeah I agree with this. Though most of the problems were hasLayout, alpha transparency and some of the default browsers styles were a bit messed up with forms. When I still had to support IE6, I still managed okay with a small IE6 stylesheet and tried to write my CSS to work across everything.
My argument is that corporate internet doesn’t need rounded corners and other pretty things.
That doesn’t make my life easier
Though I suppose just cramming in an activex control would, hahah.
And thanks for reminding me about the hasLayout thing… oh god the nightmares; how did I forget
My favorite fix for that (from memory)
* {
zoom: 1;
}
Actually the polyfills will make your life easier.
Check out CSS3PIE for example. Gradients, Shadows and Rounded Corners in IE.
That doesn’t really add up: Firefox 3.0 came out in 2008, IE8 in 2009.
The problem with HTML V5 is…well…its a pig, it really is. Everyone is pushing it as a flash replacement but frankly I can open SD flash on even the 1.8GHz Sempron I keep at the shop for a nettop and the video is smooth, even without any GPU acceleration, whereas with HTML V5 I’ve found anything short of a dual core to be a slideshow unless you have a dedicated H.264 decoder onboard.
I have a feeling we are gonna look back in 3 years and go “Remember Flash? I really miss that” because unless they figure out a way to fix it HTML V5 not only supports just a subset of the use cases Flash did but it does so while sucking CPU cycles like a drunk sucks down a free mini-bar, its just plain awful.
If HTML5 video is choppy it’s the fault of your browser and it’s HTML5 video implementation, not HTML5.
It is due to the codec. Anything less than AMD 64 3000+ series processor will have problems without GPU acceleration, they just don’t have the grunt.
Unlikely due to the codec. Chrome uses ffmpeg and its libavcodec. Opera uses GStreamer, ffmpeg/libavcodec also being its primary codec. FF probably the same. And all of them display that poorer-than-Flash performance when playing HTML5 video.
However, GNOME/GTK+ software using GStramer (Totem for example) has significantly better, proper performance. Mplayer, VLC, ffdshow (all using ffmpeg/libavcodec) also have proper performance – in fact, they are among the best performing software video players around.
Hell, using a small trick to embed MPlayer in a browser, redirecting video streams to it, results in… significantly better, “native” performance of streaming video playback (certainly better than HTML5 video, but also better than Flash; on processors notably slower than A64 3000+)
In one other recent discussion I mentioned to you, IIRC, my old Athlon XP 1700+ borderline-managing 720p H264 with the most optimised software decoder. It also handled SD/480p files more than fine when using the above (not the fastest) players, or Flash (this one again borderline, but still). HTML5? …well, no way to check now, but I seriously doubt it.
Maybe there’s something wrong with HTML5 video specs and/or what it tries to do & how it must be implemented due to that. Maybe Tim Berners-Lee was on the right track with his first browser, how it opened multimedia files in separate windows, IIRC…
Edited 2012-10-06 18:34 UTC
Known bug… at least for Firefox.
https://bugzilla.mozilla.org/show_bug.cgi?id=495727
Given that it’s been three years, I’m starting to wonder how one would get through to the Firefox developers that people are getting tired of waiting.
Yeah, but it’s like bassbeast describes under every browser… so maybe there’s something wrong with the specification and/or what it tries to do & how it must be implemented because of that.
Especially noticeable on older or netbook-class machines – when going from Flash to HTML5 video, the performance very clearly degrades (contrary to claims of how it was supposed to be…), often to the point of making video playback unusable at the same quality levels.
jQuery already solved the DOM problem.
Edited 2012-10-02 03:05 UTC
The problem with web apps is that (originally) HTML was mostly designed/intended for static documents. For remote applications there were other protocols (e.g. X).
Since then, many different people with many different goals have hacked up work-arounds/extensions to solve problems caused by “not intended for remote applications to begin with” (and problems in other areas, and problems caused by other people’s hacks/work-arounds). Because the result is a steaming pile of puke, other people try to create frameworks, etc to hide the underlying puke-fest (but the existence of many different frameworks just adds to the unnecessary complexity/confusion for web app developers, like a thick layer of turd icing on top of a multi-layered puke cake).
The basic idea is that the server tells the client what to display, what user input is allowed and what user input the server wants to know about; and the client displays what it’s told to display and gathers the input from the user. It wouldn’t be hard to create a clean/elegant way of doing this.
Sadly, the only organisation that would be capable of getting a clean/elegant alternative accepted/supported by the industry is the same organisation that is responsible for a lot of the ungodly mess we have now (W3C).
– Brendan
This happens to most software eventually, It out grows it s intended use.
TBH, if you keep JS, CSS and HTML actually separated and adhere to that you can write some pretty good maintainable webpages. Unfortunately most web developers think well made means “It works okay in my version of Firefox/Chrome”.
Edited 2012-10-02 04:55 UTC
That is why after a decade in the trenches trying to bend the browsers to do stuff they were never intended to do, I have switched my mind and now state if you want an application, make it native.
As it should be in first place, browsers are for documents.
Cool startups like to say how the web is the future, but they never have to discuss layout issues or look-and-feel, of browser behaviour vs OS defined guidelines, to get the customer to pay the project.
Or browser performance vs native performance for that matter.
In the end, applications should be done native. Easiness of installation can be achieved with things like ClickOnce, Java Web Start, or simple package repository.
moondevil,
“In the end, applications should be done native. Easiness of installation can be achieved with things like ClickOnce, Java Web Start, or simple package repository.”
I hear you, three cheers for easy distribution of native apps. There are many kinds of apps for which browser based solutions aren’t nearly as good. But many modern platforms are forcing us (devs/users) to make a contrived choice: submitting to and empowering corporately imposed walled gardens, or standing up for our freedom with (thus far unregulated) web apps. Given this choice, I’d go for freedom almost every time.
JWS was an excellent model for what mobile apps should have been; native apps which are as easy as using a website. However this possibility is largely being foiled by mobile manufacturers who are willing and able to promote platforms that enforce themselves as native application middle-men. This way they can collect royalties over 3rd party apps which they couldn’t do if things like JWS were allowed.
Edited 2012-10-02 06:15 UTC
While I don’t like the walled gardens of the mobile platforms, they are not new to me.
This is how the games industry works since the famous crash in 1982.
But you’re right, if we don’t stand against it, we might end in a scenario where all computing devices look like games consoles. Where only a few overlords are allowed to develop software.
Hm, but not so much in Europe (which you should know, I guess ;p ), that crash being North American; and generally the Europeans being largely into 8 and 16-bit microcomputers.
Only near/after the death of Amiga, our area really seemed to embraced games consoles – somewhat with Genesis & SNES, and then the craze of PS1.
JavaScript is quite an awkward little language.
Is anyone else able to keep up with all the fly by night scripting languages? They all might have some merit, but I’m suffering from so much information overload that I’m even starting to blank out on which features belong to which languages.
Here’s an idea; we need a search engine dedicated to solving the information overload caused by having so many programming languages.
I think in the future, we’ll have meta-languages, and all software will be written in one-off domain specific languages. Any further improvements will just be people reinventing new one-off DSLs and a complete reimplementation.
There’s just too many languages, and too many subtly different styles of programming and too much closed development to make education in languages, styles and legacy codebases worthwhile.
Google has two? Which other one does the author mean besides Dart? GWT? I think the GWT team moved more or less to Dart.
Yes, there was a Dart/GWT Google IO talk where the GWT team discussed the port of GWT to Dart in the future.
The problem with Dart is that the JavaScript that it generates is massive and it doesn’t seem to work with existing libraries (jQuery).
Edited 2012-10-02 04:57 UTC
My problem with Dart, TypeScript and thousand other languages that compile to JavaScript is that they are not JavaScript.
I don’t need to add more hours to my work time to spend mapping JavaScript code back to whatever was the original source code.
People should learn to stop complaining about JavaScript, period. Don’t like?
Then go code native applications which talk to the server with normal plain network protocols.
The thing is that is ultimately unrealistic.
I been doing Web Development properly now for 3 years and while I am quite comfortable writing jQuery plugins and large scripts.
The prototype based OOP, along with the function scoped variables is a PITA to get your head back into after coming from something sensible like C#.
Also when reading pure JavaScript, from someone who does just JavaScript for a living … It pretty hard to read.
If these transcompilers can be mapped to the JavaScript code easily, then I am all for them because it makes my life simpler as a C# developer that occasionally does JavaScript.
Sorry to say, but that sounds like an hammer for every nail, screw…
I never bought into “one language fits all” thing.
edit: typo
Edited 2012-10-02 08:20 UTC
Neither have I.
However for what JavaScript does and the fact that it is significantly different to how every server side popular server side language works when it comes to OOP. There are also lots of caveats when dealing with types, which if you aren’t aware of will trip you up.
I see a lot of JavaScript atrocities because:
1) Not a proper language
2) Not understood properly by most developers, especially when they come from a Java, C# or similar background, because it looks similar to them.
I like writing code in JavaScript, but I think the syntax of the language is misleading to how it actually works, and there is a lot you got to learn that isn’t obvious about the language (hoisting for example). I am not surprised people are looking for alternatives.
If you ask me last year I would have had a totally different opinion.
Edited 2012-10-02 08:59 UTC
I see.
Thanks for explaining your point of view.
In my particular case, I’ve learned OO in multiple languages besides the OO model that is known to the majority via C++, Java and similar languages.
Dylan, Self, CLOS, Modula-3, Oberon, BETA, Eiffel, Sather, Smalltalk, SWI Prolog, were a few languages that showed me different ways of doing OO. Not all of them to my liking.
I was lucky that my CS degree had a strong focus in language and compiler design.
When I said “not a proper language”, I meant “considered by some developers as not a proper language”.
🙂
Heh. Here we go again.
Someone else has said to themselves “Javascript is cool, but it’s also rubbish. Lets make it better.”
It’s a fine sentiment, and clearly popular, if Dart, Typescript, Ecmascript6 and particularly Coffeescript are anything to go by.
But in the end, what is the point?
Javascript is popular for one reason alone: it runs in the browser, and it runs the same(ish) in all browsers.
Without that fact, Javascript has zero reason to continue existing.
But the problem for all these initiatives to improve it, is that this same fact also ties us down to sticking with Javascript. It’s the “lowest common denominator” problem — we have to write code that works in all browsers, so we have to write Javascript. And we can’t even use the latest features of the language because we need to support older browsers.
And then there’s this bizarre notion of running JS code on the server. Node.js. WTF?? Why on earth would you take the most poorly designed language you can find and cram it into a whole new environment?
Two answers: (1) because all the work in the browser end lately has left us with insanely fast Javascript interpreters, which screams past every other scripting language you can think of, and (2) because developers want to write code in the same language for the client and server.
Again, it’s not the quality of the language that’s driving Javascript’s adoption, it’s the browser. It’s all about the browser.
The thing is, the more people get drawn into Javascript, and the more universal it becomes, the more it’s flaws become apparent. People get an itch to fix them, and you get Coffeescript. Or Dart. Or Typescript.
But none of them solve the actual problem, which is that we actually still have to work with Javascript.
So how do we solve this actual problem? Well it seems that the only real solution is progressive enhancement. The Ecmascript 6 approach. Improve the language one step at a time; browsers implement the new features; users upgrade their browsers, and slowly over a period of time we end up with a better language.
Typescript, Dart and even Coffeescript are doomed to failure because they aren’t part of this process. The main reason they keep trying anyway is impatience. “Why wait three years for everyone to upgrade their browsers when we want new shiny stuff *now*?”
The one place where these languages might have a chance is on the server, where they could replace the insanity that is Node.js.
But even here, the question is: what’s the point? Why create a language based on Javascript at all? We all know it’s not a good language, so why start with it in the first place?
What you really need for this is not to enslave yourself to improving JS, but create a language that starts on a fresh footing, maybe draws from JS, but also from elsewhere, and most importantly doesn’t make the mistakes made in JS. But equally important (it seems, given Node’s success) is to have a blisteringly fast script interpreter.
Oh, and getting buy-in from the developer community would help too. Get it standardised and ratified. Collaborate with the industry rather than going it alone — Google, Microsoft, everyone else: Talk to each other. Create something together. Dart has languished because Google is too much in control of it. Maybe we have learnt something from Java after all. Coffeescript has done fairly well because it’s not controlled by a big corp. That still doesn’t make Coffeescript a good idea, but we need to learn from its success.
Sorry. I’ll stop ranting now. I’m willing to bet no-one will agree with a word I’ve said, but never mind.
It also doesn’t help that Google has stated, from the beginning, that translating to Javascript is a crutch and their goal is to get a native Dart runtime in the browser.
That got people’s backs up on the WebKit mailing list and they refused to merge Google’s patches because they don’t want another VBScript.
If we ever get native support for something like CoffeeScript, it’ll be because everyone was using it anyway with no intent to have native browser support but in a way that makes it possible (eg. similar to how Protovis supports a custom type=”” attribute on script tags) and then some developer realized they could get better performance using a custom VM.
Node.js is a manifestation of the will of front-end developers to become independent and gain operability over whole software stack.
It’s a social, generational thing imp.
That is easy, just code plain desktop applications.
And if you only know Javascript, HTML, and CSS? If you don’t already know something like Python (Django) or Ruby (RoR) or Java (Spring), wouldn’t learning a whole new language in addition to another GUI API (like GTK+ or Qt) and execution model miss the point of it?
At least, with Node.JS, there are some alpha-quality GTK+ bindings in development if you really don’t mind sacrificing the no-install benefits of an in-browser application.
Disclaimer: I may have the mindset of a UI/UX designer, but my primary language of choice is Python and I write both GTK+ apps and web apps using a variety of languages. I’m not a representative example and, in fact, I’m only starting to learn Node.JS because Socket.IO is much less effort than writing my own WebSockets fallback wrapper for select-based Python frameworks like Tornado.
No, that is rather a good excuse to learn something new.
Actually there are far worse i.e. PHP (which doesn’t even have a language specification), at least JS has one of those.
ObjectScript and TypeScript in one week…
It seems the world doesn’t like JavaScript. I can understand that, but I like it (not love).
Too be honest, I prefer Node.js as a better JavaScript (yes, I know Node is not a language)…