Hacker News new | ask | show | jobs
by macspoofing 2878 days ago
>I'm talking about Google efforts in general at the time.

Ok, but just to be clear, at no point did Google actually try to replace JavaScript with Java.

>You can see it in GWT

Oh come on. GWT was transpilation tool with a built-in component framework. It solved a real problem for specific use-cases and was primarily adopted by enterprise developers. It was never a replacement for JavaScript.

>and you can REALLY see it in the articles and efforts of Google at the time where person after person laboriously tried to make JS _behave_ like Java

Can you provide an example of this? I have no idea what you're referring to.

>The late 90s and early aughts were a battle between those that wanted to recreate Classical OOP in JS and those that wanted JS to be what it has ended up being.

And Google was a non-factor in the development of the web technologies and standards in the late 90s and early 00s (Chrome wasn't released until 2008. Ajaxy Gmail was released in 2004). Also, nobody gave a crap about JavaScript in the 90s and early 00s (Crockford's JS:The Good Parts wasn't released until 2008). Maybe you're thinking of the development of ActionScript 3.0 which had OO constructs and was supposed to be a replacement for JavaScript before (I believe) Microsoft balked and left Adobe hanging. Which is a shame because AS3 is also superior to ECMAScript 5 and world would have been better with AS3 in the browser (and don't get me wrong, AS3 is very quirky language).

But regardless, the whole "Google is trying to replace JavaScript with Java" was pure paranoia not grounded in fact.

> the issue (generally) isn't static typing but instead the cost/benefit involved

You can build in optional typing if you really want to (AS3 had that). Having said that, I cannot see what time you lose by enforcing type constraints. And dynamic languages are not faster or more productive. At best it's a no-op. At worst you're dealing with runtime errors which are 100x painful and costly than dealing with a compile-time error.

>There's a reason JS has spread so far

It's the lingua franca of the web because it's the only language supported by major browsers. That's why it spread so far, not because it is a great language. In fact, the plethora of transpilation tools should give you a clue how shitty this language is.

1 comments

> But regardless, the whole "Google is trying to replace JavaScript with Java

A claim I didn't make. They TREATED Javascript like Java, and tried to adopt the behaviors. This generally works poorly in any language transition. I've seen Perl written like C, Python written like Java, Java written like Perl, etc, and it's always a bad thing.

> GWT was ....never a replacement for JavaScript.

I never said it was (You'll see a recurring theme in your responses here...). GWT, however, wasn't going to encourage me to trust Google's recommendations.

> Can you provide an example of this? [treating Javascript as Java] I have no idea what you're referring to

Ironically it's hard to come up with a lot of material from that time period, but generally you can see the number of libraries that would try to create Classical inheritance so we could use Java OOP conventions. Far too many books came out that would spend their first chapters creating such a library, and then use that library for all the rest of the book, meaning that if you want to write other styles or learn JS strengths and quirks, you were out of luck - instead you learned that JS does not do a good job of recreating a Java-like code structure.

> Google was a non-factor in the development of the web technologies and standards in the late 90s and early 00s

You are correct - my memory tends to forget how far away some of those experiences were. I was talking mid-aughts to 2011 ish. starting pre-Chrome, but going through Chrome, GWT, GWA). Google released the first generally used styleguide for JS, got vocal in standards discussions, etc. By the time Dart and NaCl came around (2011?) Google had established themselves as worth listening to, but also worth taking salt with (pun retroactively intended).

I mean, if someone shows up and starts saying the language is shitty and we should all be doing it differently, we're going to take whatever they say a little skeptically.

> I cannot see what time you lose by enforcing type constraints

Enforcing? Generally not much. Giving the info so the system can do it? Quite a bit. Not worth breaking down here, I'll just say that the market is clearly not convinced by your arguments, and you can dismiss them as idiots if you like, I'm just saying there are a lot of people that don't think static typing is automatically the best thing to do.

> how shitty this language is

A debate not worth having as you've clearly made up your mind. Nonetheless, to stick to the original point: Dart wasn't given a fair shake, but Google had not put themselves in a position to be considered a good source of "future of web dev languages across browsers" trust, despite their efforts to improve dynamic web apps and the browser space in general. I heard the "Replace Javascript with Java" rumors, but everyone that I respected disregarded that and instead focused on developing Javascript as Javascript. That doesn't always make their choices correct (ask me about CSS sometime!) but it does suggest that their reaction to Dart was not solely motivated out of a fear of replacing JS with Java. I myself was not a fan of JS when Dart was announced, but had no interest in picking up a Chrome-only feature, particularly when everyone focused on how it wasn't JS instead of how it would make my job easier. Not being JS is fine, but if it comes across as NIH because your bikeshed is better, I have little interest.

>A claim I didn't make. They TREATED Javascript like Java, and tried to adopt the behaviors.

Again, because you're making nebulous claims it's really hard to argue against. I still don't see how Google treated JavaScript like Java. I don't know what that entails.

>Ironically it's hard to come up with a lot of material from that time period, but generally you can see the number of libraries that would try to create Classical inheritance so we could use Java OOP conventions.

You must be thinking about the Closure Compiler[1], which was a transpilation solution driven by JavaScript comments which provided type and directive decorations around raw JS source allowing compile-time checks. All it was a proto-TypeScript. Do you think TypeScript is Microsoft attempt to treat JavaScript like Java, because TypeScript provides OO constructs (like classes, inheritance, polymorphism)? Because that's what you're saying.

>Ironically it's hard to come up with a lot of material from that time period,

And my argument is, you won't find anything, because there was nothing to it. It was irrational and emotional argument.

>I mean, if someone shows up and starts saying the language is shitty and we should all be doing it differently,

And they were right. For example, people complained about NaCL/PNaCL (sometimes for good reasons, it was a proprietary solution) but WebAssembly is the spiritual successor to NaCL/PNaCL. JavaScript is still terrible for writing large amounts of code and this is why people use TypeScript to make it palatable.

>I'll just say that the market is clearly not convinced by your arguments

I would respectfully disagree. And my counter argument is the popularity and plethora of transpilation languages and pre-processing frameworks for the entire browser tech stack (HTML/JS/CSS). If you're writing 100k lines of JS code, you're not writing it in vanilla JavaScript, unless you're a sado-masochist and you like pain. Front-end devs have also come around on static typing because you really don't know pain until you start dealing with what should be trivial bugs in a large application written in a dynamic language. Compile-time checks and AOT optimizations are incredibly powerful tools.

[1] https://developers.google.com/closure/compiler/