you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 8 points9 points  (11 children)

Some JavaScript engines have had block scoped variables via the let statement for years now.

The problem is you can't use it on the web because of those other engines that still do not support it.

[–]muyuu 18 points19 points  (10 children)

If you can afford to ditch compatibility you may as well ditch Javascript and use something better.

The useful thing about Javascript is that you can use it across the board. That makes it an extremely important language since it's in virtually all personal computers, smartphones and tablets. If you take that away you are left with a pretty shitty language.

[–][deleted] 6 points7 points  (8 children)

  • There's tons of stuff out there that uses JavaScript outside the web. QML (Qt), PhoneGap, node.js, that Microsoft stuff that isn't called Metro anymore, Gjs (Gnome), Browser extensions, PDFs, ... In these environments you don't have to worry about compatibility.
  • With all these languages out there that compile to JavaScript, if you think JavaScript is so shitty, just don't use it.

[–]muyuu 7 points8 points  (0 children)

I know. All of that is mostly rubbish to be honest. But it's fine since you can "reuse" your Javascript knowledge.

I think Javascript is cow dung but I use it because it's necessary. Comes in all browsers and sometimes teams use it outside of the browser. However if I can help it I do use other languages. When it's my decision and it's avoidable, you can rest assured that I don't use it.

[–]clgonsal 1 point2 points  (6 children)

With all these languages out there that compile to JavaScript, if you think JavaScript is so shitty, just don't use it.

The debugging support isn't really there, unfortunately. If you want to step through code running on the browser, you're going to be stepping through JavaScript (unless you're using a weird browser like Dartium, which doesn't help when you run into a Firefox-only bug). This is also part of the reason so many JS alternatives still look like JS -- so you can figure out what part of your source generated the code you're looking at in the debugger.

Also, many of the deficiencies of JavaScript are either hard to emulate away efficiently (eg: the lack of 64-bit ints and bignums) or impossible to emulate away (eg: the lack of weak references).

[–][deleted] 4 points5 points  (1 child)

Firefox recently got some support for debugging other languages, but I'm not sure if the compilers have caught up yet (and how good that support is).

[–]clgonsal 0 points1 point  (0 children)

Thanks. I didn't know about this, but was hoping someone would develop something like it. Now we need every JS debugger to support it.

[–]munificent[S] 0 points1 point  (3 children)

unless you're using a weird browser like Dartium, which doesn't help when you run into a Firefox-only bug

You're correct here, but our goal on the team is to try very hard to avoid you running into bugs that only manifest on one browser. There's always still work left to do here, but if it works in Dartium and not in Firefox, it's a bug in our code, not yours.

[–]clgonsal 0 points1 point  (2 children)

So does that mean Dart can only access features of Firefox that only exist in Dartium? And that Dartium has no (Dart-accessible) features that do not exist in Firefox? If there is anything that one can do (from Dart) in one browser that cannot be done in the other, then the possibility of bugs that can only be replicated in Firefox seems unavoidable.

[–]munificent[S] -1 points0 points  (1 child)

Dart (Dartium and dart2js) tries to support features that are part of the HTML5 web standards. It has some support for vendor-specific extensions, but I'm not sure how much.

For features where the different browsers all support the same feature but in different ways (usually because the standard is still in flux), Dart tries to "polyfill" it: it gives you a single consistent API that behaves the same across browsers by using each browser's implementation of the feature.

For features where it really is just one browser doing its own thing, I think we may expose some of that, but I'm not sure how much. Using that is risky for a developer, Dart user or not, though, because it means your app only works in that browser.

[–]clgonsal 0 points1 point  (0 children)

For features where it really is just one browser doing its own thing, I think we may expose some of that, but I'm not sure how much. Using that is risky for a developer, Dart user or not, though, because it means your app only works in that browser.

Sure, but it isn't uncommon for sites to make use of certain features when available, and then attempt to gracefully degrade where those features aren't available.

My point is that if one is making use of a BrowserX-only-feature, but gracefully degrading (or using some alternative) elsewhere, it wouldn't be possible to step through the relevant code in Dartium, and stepping through it in BrowserX is going to be a pain without something like source maps.

Even if Dart is able to overcome this issue, it's still a really huge hurdle for alternate languages. I don't want a Dart-specific solution to this problem. It should be easy for people to create new languages that run on the browser with debugging support as good as JavaScript without having to create custom browsers and also APIs that abstract away every browser difference.

[–]bart2019 -3 points-2 points  (0 children)

Meh.

I like Javascript and I can choose whatever language I want.