JavaScript Conquered the Web, Now It’s Taking Over the Desktop(wired.com)
wired.com
JavaScript Conquered the Web, Now It’s Taking Over the Desktop
https://www.wired.com/2016/05/javascript-conquered-web-now-taking-desktop/
269 comments
I can't believe this is the top comment. Let's go point by point:
1) JavaScript has its warts and its gotchas like anything else (okay, maybe a few more). So what? Spend 50 hours building anything substantial with JavaScript and you'll get a good handle on them, and you'll be good to go for the next 10,000 hours. Same goes for just about any other language. Focusing on the weird edge cases might make for a nice blog post, but it's not relevant to people actually building things day to day.
2) Growing pains in a very active community? Unheard of! Okay, so this was embarrassing and disappointing, but at least it's been dealt with. You can keep pointing to it if it helps your argument, but that doesn't make it valid.
3) I don't really understand what point you're trying to make here.
4) Again, very active community. Lots of churn. Plenty of reinventing / rediscovering the wheel. If that _really_ bothers you and you're struggling to separate the signal from the noise, I at least understand and respect that criticism. I don't think that's a reason for anyone to stoop to the level you have, though.
1) JavaScript has its warts and its gotchas like anything else (okay, maybe a few more). So what? Spend 50 hours building anything substantial with JavaScript and you'll get a good handle on them, and you'll be good to go for the next 10,000 hours. Same goes for just about any other language. Focusing on the weird edge cases might make for a nice blog post, but it's not relevant to people actually building things day to day.
2) Growing pains in a very active community? Unheard of! Okay, so this was embarrassing and disappointing, but at least it's been dealt with. You can keep pointing to it if it helps your argument, but that doesn't make it valid.
3) I don't really understand what point you're trying to make here.
4) Again, very active community. Lots of churn. Plenty of reinventing / rediscovering the wheel. If that _really_ bothers you and you're struggling to separate the signal from the noise, I at least understand and respect that criticism. I don't think that's a reason for anyone to stoop to the level you have, though.
> Spend 50 hours building anything substantial with JavaScript and you'll get a good handle on them, and you'll be good to go for the next 10,000 hours.
Spending 10,000 hours building things with JavaScript sounds like a pretty good definition of Hell.
JavaScript is an actively, abusively bad language. It's not that it has a few warts: it's nothing but warts. Its fundamental design flaws are obscured only by its superficial design flaws.
It's a really bad, tasteless language.
> I don't think that's a reason for anyone to stoop to the level you have, though.
I really don't think he 'stooped' to anything.
Spending 10,000 hours building things with JavaScript sounds like a pretty good definition of Hell.
JavaScript is an actively, abusively bad language. It's not that it has a few warts: it's nothing but warts. Its fundamental design flaws are obscured only by its superficial design flaws.
It's a really bad, tasteless language.
> I don't think that's a reason for anyone to stoop to the level you have, though.
I really don't think he 'stooped' to anything.
In case Eich reads your comment: given that it had to be done in ten days and "look like Java", JavaScript is a fine langauge.
(But yeah, compared to languages that were designed over years obviously it's incredibly bad.)
To quote Eich (from here[1]):
" Ten days to implement the lexer, parser, bytecode emitter (which I folded into the parser; required some code buffering to reorder things like the for(;;) loop head parts and body), interpreter, built-in classes, and decompiler. I had help only for jsdate.c, from Ken Smith of Netscape (who, per our over-optimistic agreement, cloned java.util.Date -- Y2K bugs and all! Gosling...).
Sorry, not enough time for me to analyze tail position (using an attribute grammar approach: http://wiki.ecmascript.org/doku.php?id=strawman:proper_tail_...). Ten days without much sleep to build JS from scratch, "make it look like Java" (I made it look like C), and smuggle in its saving graces: first class functions (closures came later but were part of the plan), Self-ish prototypes (one per instance, not many as in Self).
I'll do better in the next life. "
[1] Edit: jwz.org intercepts HN links. See mjgoeke's comment.
(But yeah, compared to languages that were designed over years obviously it's incredibly bad.)
To quote Eich (from here[1]):
" Ten days to implement the lexer, parser, bytecode emitter (which I folded into the parser; required some code buffering to reorder things like the for(;;) loop head parts and body), interpreter, built-in classes, and decompiler. I had help only for jsdate.c, from Ken Smith of Netscape (who, per our over-optimistic agreement, cloned java.util.Date -- Y2K bugs and all! Gosling...).
Sorry, not enough time for me to analyze tail position (using an attribute grammar approach: http://wiki.ecmascript.org/doku.php?id=strawman:proper_tail_...). Ten days without much sleep to build JS from scratch, "make it look like Java" (I made it look like C), and smuggle in its saving graces: first class functions (closures came later but were part of the plan), Self-ish prototypes (one per instance, not many as in Self).
I'll do better in the next life. "
[1] Edit: jwz.org intercepts HN links. See mjgoeke's comment.
I'd recommend copy+pasting the link to www.jwz.org if you want to open it...
https://www.jwz.org/blog/2010/10/every-day-i-learn-something-new-and-stupid/#comment-1048> The ecosystem is terrible and the community is full of self-righteous assholes who has the collective attention span of a 2 year old
> I don't think he 'stooped' to anything
Really? This is supposed to be a place for civil, mature discussion. There are plenty of valid arguments against javascript as a language and as a community, there's no need for childish comments like that.
> I don't think he 'stooped' to anything
Really? This is supposed to be a place for civil, mature discussion. There are plenty of valid arguments against javascript as a language and as a community, there's no need for childish comments like that.
I don't understand why people say javascript is such an awful language. The "Wat" video previously posted features of a few javascript idiosyncrasies, but I think most people would consider such obscure syntax combinations to be ill mannered, and most people understand to be very careful around type conversions.
At a higher level of organization, the language begins to matter less and less, and what matters more are that subcomponents within a larger system obey their contracts, and that there's some concurrency strategy if you have distributed state.
At a higher level of organization, the language begins to matter less and less, and what matters more are that subcomponents within a larger system obey their contracts, and that there's some concurrency strategy if you have distributed state.
I don't understand why people say javascript is such an awful language.
Frankly, because from a language design perspective, it is - or at least used to be: Bad scoping rules (implicit global declarations by default, function instead of lexical block scope if var is present), weird implicit conversions, no good story for code reuse/object extension so everyone doing anything complex had to cook up their own version, ...
Nevertheless, I actually enjoy programming in Javascript ;)
Frankly, because from a language design perspective, it is - or at least used to be: Bad scoping rules (implicit global declarations by default, function instead of lexical block scope if var is present), weird implicit conversions, no good story for code reuse/object extension so everyone doing anything complex had to cook up their own version, ...
Nevertheless, I actually enjoy programming in Javascript ;)
>> Spend 50 hours building anything substantial with JavaScript and you'll get a good handle on...
I don't mind MY JavaScript. It's everyone else's that drives me bonkers. Tracking down things in JS is a timesuck of epic proportions. Much of the time, it just isnt't any fun.
I don't mind MY JavaScript. It's everyone else's that drives me bonkers. Tracking down things in JS is a timesuck of epic proportions. Much of the time, it just isnt't any fun.
> I don't mind MY JavaScript. It's everyone else's that drives me bonkers. Tracking down things in JS is a timesuck of epic proportions. Much of the time, it just isnt't any fun.
You should look into typescript, it has helped us quite a lot with that particular matter.
You should look into typescript, it has helped us quite a lot with that particular matter.
> Tracking down things in JS is a timesuck of epic proportions.
I think you mean your codebase rather than JS. There are plenty of industrial JS codebases where this is not a problem.
I think you mean your codebase rather than JS. There are plenty of industrial JS codebases where this is not a problem.
I'll be the first to confess I'm not a JS wizard. That being said, it'd be nice for the following to be easier:
* figuring out which events are listening to a given DOM element at any given time
* sane debugging for things Facebook Coonnect, which had a really confusing implementation at my last company
* no magically defined functions or variables (i.e. foo["bar"+ someId] = eval("function () {...}")
* keeping CSS out of JS, and JS out of HTML
* dealing with features tightly coupled to an ancient jQuery plug-in
I could go on forever... JS isn't necessarily that bad, but the way people use it is often suboptimal.
* figuring out which events are listening to a given DOM element at any given time
* sane debugging for things Facebook Coonnect, which had a really confusing implementation at my last company
* no magically defined functions or variables (i.e. foo["bar"+ someId] = eval("function () {...}")
* keeping CSS out of JS, and JS out of HTML
* dealing with features tightly coupled to an ancient jQuery plug-in
I could go on forever... JS isn't necessarily that bad, but the way people use it is often suboptimal.
Not to be too pedantic, but most of those things have nothing to do with JS.
> figuring out which events are listening to a given DOM element at any given time
This is part of the DOM Specification, not JS. You may be using JS to manipulate and listen to the DOM, but the reason that browsers don't support doing thing X natively is because the DOM Specification does not specify it.
> * sane debugging for things Facebook Coonnect, which had a really confusing implementation at my last company
Again, this is about a Facebook client library, not Javascript.
> * no magically defined functions or variables (i.e. foo["bar"+ someId] = eval("function () {...}")
If you mean the use of eval to change the runtime environment, pretty much every dynamic language supports some form of eval. It would also be impossible to write certain types of code without eval.
> * keeping CSS out of JS, and JS out of HTML
Not sure how this is a criticism of JS.
> * dealing with features tightly coupled to an ancient jQuery plug-in
Again, this is a common software engineering problem, and has nothing to do with Javascript.
I think you've illustrated some of the reasons that Javascript is so apparently unpopular -- often (but not always) people reference some aspect of the DOM, or jQuery, or whatever vendor-hacked snippets from the late 90s that they remember, without considering that the "bad" parts of the language are by now well known, and there exist extremely efficient and standards-compliant, double-JIT'ed runtimes for JS.
> figuring out which events are listening to a given DOM element at any given time
This is part of the DOM Specification, not JS. You may be using JS to manipulate and listen to the DOM, but the reason that browsers don't support doing thing X natively is because the DOM Specification does not specify it.
> * sane debugging for things Facebook Coonnect, which had a really confusing implementation at my last company
Again, this is about a Facebook client library, not Javascript.
> * no magically defined functions or variables (i.e. foo["bar"+ someId] = eval("function () {...}")
If you mean the use of eval to change the runtime environment, pretty much every dynamic language supports some form of eval. It would also be impossible to write certain types of code without eval.
> * keeping CSS out of JS, and JS out of HTML
Not sure how this is a criticism of JS.
> * dealing with features tightly coupled to an ancient jQuery plug-in
Again, this is a common software engineering problem, and has nothing to do with Javascript.
I think you've illustrated some of the reasons that Javascript is so apparently unpopular -- often (but not always) people reference some aspect of the DOM, or jQuery, or whatever vendor-hacked snippets from the late 90s that they remember, without considering that the "bad" parts of the language are by now well known, and there exist extremely efficient and standards-compliant, double-JIT'ed runtimes for JS.
You are forgetting that even Eich didn't want to do JS; he wanted to embed Scheme but was overruled by suits at Netscape who wanted to ride the Java hype. That's why the semicolons and curly braces. It really is indefensible on technical grounds.
I think they also told him to make it forgiving, like html, so that beginners could use it. Thus the implicit conversion rules, optional semicolons, being able to leave new off a function constructor, not having to use var, and so forth.
It's too bad nobody pumped the brakes after it was a little successful, and said "Okay guys, let's stop dicking around and do this right now, before we have to deal with it for the next 30 years". Alas...
These laundry lists of js warts get dragged out continually, so I really have to ask: How are you people actually developing in javascript and haven't yet discovered linters?
Linters have been around for over a decade and solve all of these issues (as they do in other languages as well). They're also easily integrated in every text editor and build system I've ever seen.
And why shouldn't the interpreter support these rules? Because a linter can do this almost as easily, and not break backward compatibility.
Linters have been around for over a decade and solve all of these issues (as they do in other languages as well). They're also easily integrated in every text editor and build system I've ever seen.
And why shouldn't the interpreter support these rules? Because a linter can do this almost as easily, and not break backward compatibility.
The same can be said for C's flaws. Just use a linter.
That didn't stop people from wanting to come up with or use different languages in place of C, where possible.
That didn't stop people from wanting to come up with or use different languages in place of C, where possible.
What state was guile in at the time? Could we have ended up with that instead of javascript?
If only web developers would unite and put an end to JS once and for all.
This is really sad, a whole industry that was once inspired by Unix philosophy and was supposed to be beautiful and fun, is now conquered by languages like JS, php, and Java: so ugly and so not fun.
I always thought programming should be something you do cause you like it, not because you're forced to do it. If you use JS cause "everybody else uses it" and "it pays more", then I'm sorry, you're screwed. I thought CS industry belongs to developers, not tech giants (Oracle, Microsoft, ...) who force Java and JS on everybody.
Someday, some body will stand up and say "Enough is Enough".
Edit: If you want to downvote, at least please tell me why I'm wrong...
This is really sad, a whole industry that was once inspired by Unix philosophy and was supposed to be beautiful and fun, is now conquered by languages like JS, php, and Java: so ugly and so not fun.
I always thought programming should be something you do cause you like it, not because you're forced to do it. If you use JS cause "everybody else uses it" and "it pays more", then I'm sorry, you're screwed. I thought CS industry belongs to developers, not tech giants (Oracle, Microsoft, ...) who force Java and JS on everybody.
Someday, some body will stand up and say "Enough is Enough".
Edit: If you want to downvote, at least please tell me why I'm wrong...
> (Oracle, Microsoft, ...) who force Java and JS on everybody.
Why call out Microsoft? They aren't forcing Java or JS. They came up with C# and Typescript instead.
I can't speak to Typescript, but C# is way more fun to write than Java. It's not particularly interesting or glamorous, but it is nicer to write.
Why call out Microsoft? They aren't forcing Java or JS. They came up with C# and Typescript instead.
I can't speak to Typescript, but C# is way more fun to write than Java. It's not particularly interesting or glamorous, but it is nicer to write.
We've converted all our JS to TS, huge timesaver.
I meant in general. Microsoft did force their flawed Windows on everybody anyway.
Microsoft forced Windows on everyone, therefore by the transitive property of online griping, Microsoft also forced JS and Java on everyone? But in general, so it makes sense.
This is like saying Coca-Cola is responsible for the high sugar content in Hershey's chocolate. In general.
Disclosure: Microsoft employee.
This is like saying Coca-Cola is responsible for the high sugar content in Hershey's chocolate. In general.
Disclosure: Microsoft employee.
> Let's just call this experiment a failure
The problem with "just calling this experiment a failure"—why that won't work in practice—is that JavaScript is not a failure. It's extremely successful.
The problem with "just calling this experiment a failure"—why that won't work in practice—is that JavaScript is not a failure. It's extremely successful.
And it is extremely successful because it's not a bad language. Sure, there's lots of "wat", but a non-professional programmer is going to say "wat" about every strange error they get from another programming language that js would have just passed silently with a weird result. Then they will replace whatever construct isn't working with one that does, and get on with their life, unlike people who seem to have a lot of energy to waste on complaining.
Are there bad languages? Can you give an example of a such language?
I'm also wondering why JS changed so much lately if it was a great language already.
When I first started learning JavaScript, I wondered how people became proficient at the langue with all these weird quirks[0] that don't raise errors. Turns out that there are a bevy of things to help combat these quirks. Two of them are strict mode[1] (which can be scoped[2] in instances were libraries/frameworks would fail running in strict mode) and linters.
Strict mode and linters do not fix everything. This is doubly so if your developers ignore the warnings and errors that the linter throws. The language isn't inherently bad, but plain old JavaScript is not beginner friendly for new developers. It requires the discipline to not just throw things together.
[0]: https://dorey.github.io/JavaScript-Equality-Table/unified/ [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2]:https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Strict mode and linters do not fix everything. This is doubly so if your developers ignore the warnings and errors that the linter throws. The language isn't inherently bad, but plain old JavaScript is not beginner friendly for new developers. It requires the discipline to not just throw things together.
[0]: https://dorey.github.io/JavaScript-Equality-Table/unified/ [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2]:https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
> I wondered how people became proficient at the langue with all these weird quirks[0]
(links the usual loose equality table)
Why don't you all just use === instead of ==?
Tell me, how long does it take to learn it?
Why don't you all just use === instead of ==?
Tell me, how long does it take to learn it?
I think I have used weak equality once, because I needed truthy/falsy. I've always used strong equality. I always tell people that unless there is an absolute need for weak equality and you can thoroughly explain why weak equality works better than another solution, refactor for strong equality.
The all these weird quirks thing was really a naive me talking back then. JS was my second language after Java. Anonymous functions, async execution, implicit typing, weak typing - it requires a different way of thinking when you move from Java to JS and you're just starting. Most everything is explicitly defined, and everything executes in the order that is listed in Java. JS is whole different beast.
The all these weird quirks thing was really a naive me talking back then. JS was my second language after Java. Anonymous functions, async execution, implicit typing, weak typing - it requires a different way of thinking when you move from Java to JS and you're just starting. Most everything is explicitly defined, and everything executes in the order that is listed in Java. JS is whole different beast.
There are plenty of times where you want ==, or for that matter, any falsy/truthy expression in JS... about the only points where I have issues with some of the defaults for falsy/truthy come down to the number 0... Outside that, I find that there are times where I'm dealing with inputs that can be a string or number, and the coercion can be handy.
I would never suggest people start learning programming with JS first... although, there is the huge benefit of not needing more than a text editor and browser (already on their machine) to get started with it. One area of JS that I HATE is Date... it sucks, it's woefully incomplete and moment-timezone is huge to download in a browser.
The primitives, coercion and a lot of other bits of JS I really appreciate... but === vs == is pretty low on my list... that said, I tend to prefer the airbnb eslint preset, so it makes me use it anyway.
I would never suggest people start learning programming with JS first... although, there is the huge benefit of not needing more than a text editor and browser (already on their machine) to get started with it. One area of JS that I HATE is Date... it sucks, it's woefully incomplete and moment-timezone is huge to download in a browser.
The primitives, coercion and a lot of other bits of JS I really appreciate... but === vs == is pretty low on my list... that said, I tend to prefer the airbnb eslint preset, so it makes me use it anyway.
> There are plenty of times where you want ==
FWIW, I've never used ==
FWIW, I've never used ==
FWIW, I almost always use ==. Very rarely, if ever, had any problems- probably I'm used to javascript enough to think in advance of the edge cases and use === when I feel it's necessary.
> I'm used to javascript enough to think in advance
I don't consider it a foresight issue. I'm a believer in putting the burden on the caller not the callee. If I expect 0 and you have "0", it's your job to call parseInt(), not my job to branch out some if statements for type checking and coercion. For a few reasons:
1) debugging someone else's code is a lot more time consuming than debugging your own
2) actually fixing a bug in someone else's code means a pull request to someone who may not actively maintain that code
3) the docs are simpler to write and easier to read.
It's my only pain point with the JS community. The "give me whatever and I'll see if I can handle it for you" mentality:
I'd rather be expressly told what to give you than try to read a wall of if statements in both the docs and your code.
I don't consider it a foresight issue. I'm a believer in putting the burden on the caller not the callee. If I expect 0 and you have "0", it's your job to call parseInt(), not my job to branch out some if statements for type checking and coercion. For a few reasons:
1) debugging someone else's code is a lot more time consuming than debugging your own
2) actually fixing a bug in someone else's code means a pull request to someone who may not actively maintain that code
3) the docs are simpler to write and easier to read.
It's my only pain point with the JS community. The "give me whatever and I'll see if I can handle it for you" mentality:
function doStuff(a, b, c) {
if (!c && b instanceof Function) {
c = b;
}
c()
}
I'd rather be expressly told what to give you than try to read a wall of if statements in both the docs and your code.
True, although your example is probably just an attempt to offer method overloading. But I agree that it is confusing. And you do see a lot of times functions trying to sanitise their inputs, which I agree is wrong.
It's my opinion that if I can execute without error, I should execute without error... if that means I `~~input` to make certain I'm working with a whole number, I'll do it. If someone calls me with invalid input, and it's coerced and you get invalid output, so be it.. it didn't crash/error.
That said, the biggest problem I've seen in a lot of projects, bigger than coercion and in languages including, but not limited to JS is not properly handling error cases.
That said, the biggest problem I've seen in a lot of projects, bigger than coercion and in languages including, but not limited to JS is not properly handling error cases.
> so be it.. it didn't crash/error.
That's a HUGE problem. This is an absolutely fucking nightmare. It's arguably the hardest thing to possibly debug, because you're not informed it's a bug. No amount of error handling will solve that, which you've pointed out as "the biggest problem".
> If someone calls me with invalid input, and it's coerced and you get invalid output
But this isn't the problem. The problem is when it gets called with invalid input and somehow gets coerced into a valid but unexpected output. Expected input -> Expected output means you get instant gratification as to whether or not it works. This dramatically reduces the number of error cases which naturally and effortlessly moves toward solving your complaint.
That's a HUGE problem. This is an absolutely fucking nightmare. It's arguably the hardest thing to possibly debug, because you're not informed it's a bug. No amount of error handling will solve that, which you've pointed out as "the biggest problem".
> If someone calls me with invalid input, and it's coerced and you get invalid output
But this isn't the problem. The problem is when it gets called with invalid input and somehow gets coerced into a valid but unexpected output. Expected input -> Expected output means you get instant gratification as to whether or not it works. This dramatically reduces the number of error cases which naturally and effortlessly moves toward solving your complaint.
Multiple dispatch would be a cleaner approach for languages that support multiple versions of doStuff.
[deleted]
> And it is extremely successful because it's not a bad language.
Perhaps not a bad language, but I do think it falls into the same category as PHP - just good enough.
It's just good enough to do what we want it to do, and given the lack of choice, we're willing and ready to pile abstraction upon abstraction upon it to try and reduce the pain involved with getting work done.
And like masochists, we look at the results and go "Well, that didn't hurt too bad this time, so I'm willing to go do it again."
Perhaps not a bad language, but I do think it falls into the same category as PHP - just good enough.
It's just good enough to do what we want it to do, and given the lack of choice, we're willing and ready to pile abstraction upon abstraction upon it to try and reduce the pain involved with getting work done.
And like masochists, we look at the results and go "Well, that didn't hurt too bad this time, so I'm willing to go do it again."
I don't think you know what you're talking about.
PHP, up to version 4 at least, was hardly even a language. More like a collection of macros.
Javascript, despite a few ugly gotchas, is an elegant language with a few simple rules that allow for an impressive degree of freedom and flexibility.
Javascript, despite a few ugly gotchas, is an elegant language with a few simple rules that allow for an impressive degree of freedom and flexibility.
> hardly even a language. More like a collection of macros.
You just described Forth, and a good portion of Lisp. Both of which are great, groundbreaking, and productive languages.
> an elegant language with a few simple rules that allow for an impressive degree of freedom and flexibility
Very eloquently said. However, compared to other dynamic languages like Lisp, Perl, Ruby, and Python, it doesn't strike me as particularly free or flexible. The ability to create and use DSLs directly within those languages really displays true flexibility and freedom, IMO.
Of course, you don't always want unlimited flexibility and freedom in a language; it's why a particular type-safe languages with a very restrictive borrow checker is so popular.
You just described Forth, and a good portion of Lisp. Both of which are great, groundbreaking, and productive languages.
> an elegant language with a few simple rules that allow for an impressive degree of freedom and flexibility
Very eloquently said. However, compared to other dynamic languages like Lisp, Perl, Ruby, and Python, it doesn't strike me as particularly free or flexible. The ability to create and use DSLs directly within those languages really displays true flexibility and freedom, IMO.
Of course, you don't always want unlimited flexibility and freedom in a language; it's why a particular type-safe languages with a very restrictive borrow checker is so popular.
DSLs are actually common in javascript. JQuery, one of the most popular libraries in all of javascript is mostly a DSL for DOM manipulation. Lodash/underscore is mostly a DSL for list manipulation.
Admittedly, JS doesn't have operator overloading, but I personally think that's a good thing.
Admittedly, JS doesn't have operator overloading, but I personally think that's a good thing.
We apparently have a very different definition of DSLs. Both jQuery and Lodash are, to me, libraries with lots of functions. A DSL, to me, would be a change in the underlying language being interpreted.
i.e.
i.e.
describe file("foo") do
it { should exist }
it { should be_owned_by "root" }
end
_.map(["a"], function(s) {alert(s)}) describe("something", () => {
it(should(exist))
it(should(be_owned_by, "root"))
});
_.map(["a"], s => alert(s))
_.map(["a"], alert)Except your rspec example isn't a change to the underlying language is it? Also, Check out mocha for the JavaScript equivalent.
Also, when you use only one function of lodash, you can't call it a language, but there are chains and flows for creating powerful pipelines for collection processing.
Also, when you use only one function of lodash, you can't call it a language, but there are chains and flows for creating powerful pipelines for collection processing.
Operator overloading in Python made the Pandas library possible where you can treat a DataFrame syntactically like you can in R, which is really nice for data science.
"Made it possible", or "made it look like R"? add() vs. + is just a mild inconvenience IMO compared to the inconvenience of overloading abuse that I normally see ( like sqlalchemy IMO). I'd personally rather know what to expect from an operator.
Also, it adds up (no pun intended). You're right that add() vs. + for a simple case when you only do it a few times is no big deal. But it is a bigger deal when you do it a lot, and the arithmetic can be a little more complicated.
We could by analogy apply this argument to adding integers and floats together. It's more convenient to use the + operator for that, but someone could argue that an add() function is just a minor inconvenience, so why bother overloading the + operator?
That is until you have to use it hundreds of times.
We could by analogy apply this argument to adding integers and floats together. It's more convenient to use the + operator for that, but someone could argue that an add() function is just a minor inconvenience, so why bother overloading the + operator?
That is until you have to use it hundreds of times.
It's not just arithmetic, it's also being able to use comparison operators to filter, which is really convenient. What languages like R do at the syntactic level is make the programming language closer to math, where you can do things like add vectors or multiply matrices using simple operators.
Compared to what? PHP is/was far, far worse than JS has ever been, and I remember when you couldn't declare a function in a function (IE3 iirc). There are a few, well defined quirks, and some other behaviors that are arguable, but JS is one of the most expressive languages around, and with the ES2017+ enhancements really nice.
JS is my favorite language, hands down... C# is a close second, and that's as much for the tooling as the language, though the p/invoke and native interfaces are pretty awesome. After that, there's some functional languages I like, and have been looking for a reason to use Rust or Go for something... beyond that, most languages have a lot of their own warts.
JS is my favorite language, hands down... C# is a close second, and that's as much for the tooling as the language, though the p/invoke and native interfaces are pretty awesome. After that, there's some functional languages I like, and have been looking for a reason to use Rust or Go for something... beyond that, most languages have a lot of their own warts.
>about every strange error they get from another programming language that js would have just passed silently with a weird result
Wait, do you mean to imply that "passing silently with a weird result" is somehow better than throwing a verbose, descriptive error?
Wait, do you mean to imply that "passing silently with a weird result" is somehow better than throwing a verbose, descriptive error?
Sure, but there are better alternatives, and now that JS isn't just confined to the web, where it had no real competition, people are complaining because they see it being used instead of better tools that have been available for a long time.
I don't think there is universal agreement on what the better alternatives are. If there were, comments like these would list them. There are however worse examples for desktop development never the less used on the desktop like VBA, java, adobe air, scala.
As with so many choices, there is a trade off. If it were possible to point to some system that is unambiguously better on all axes than javascript and its ecosystem, then you'd have a point, but since there isn't, we're back to arguing trade offs, and really, getting upset about the tools other people choose to make things is a pretty fruitless use of time and energy. If people really want to encourage others to move, they'd be better evangelising the solutions they love than berating people for choosing what they choose.
As with so many choices, there is a trade off. If it were possible to point to some system that is unambiguously better on all axes than javascript and its ecosystem, then you'd have a point, but since there isn't, we're back to arguing trade offs, and really, getting upset about the tools other people choose to make things is a pretty fruitless use of time and energy. If people really want to encourage others to move, they'd be better evangelising the solutions they love than berating people for choosing what they choose.
ES6 is better.
[edit] ES6 is definitely better than a swift kick in the groin. It is certainly better than the original version of javascript. And it is also better than a lobotomy.
[edit] ES6 is definitely better than a swift kick in the groin. It is certainly better than the original version of javascript. And it is also better than a lobotomy.
I mean, the whole "{} + [] == 0" thing is cute and all, but isn't that just tip-of-the-iceberg hilarity? Isn't the real problem with javascript that it's slow and messy?
I was under the impression modern JS interpreters JIT to machine code and are fast. Kind of like how Java was slow in 1995 but today is kind of amazingly fast. Which I guess implies that there are two ways a language can become fast: one is by being designed for speed, and another is by becoming extremely popular/useful and having tons of millions of hours of thought and work put into making it faster.
JS engines have improved by about 2 orders of magnitude in speed for actual use over the last 10 or so years. They've outpaced Moores law.
Probably because the head guy working on V8 had lots of experience with virtual machines going back to Self in the 80s. But it's kind of silly to say that JS VMs have outpaced Moore's law, given that interpreted JS was very slow to begin with. It's not the same as a compiled languge improving by that much in the same time.
Basically, JS wasn't leveraging much of the computer's power until V8 came along.
Basically, JS wasn't leveraging much of the computer's power until V8 came along.
It seems that you're complaining about some perceived meaning in my comment, but I'm not sure what it was.
Having written significant pieces of code in javascript over the last 13 years, I've benefitted massively from those speed increases, and while I'm aware of a number of reasons that they have occurred (including but not limited to the v8 engine - I remember reading excitedly about tamarin, tracemonkey and the like), I don't think it's silly to point out the sheer magnitude of the improvement.
I'm not trying to say that JS is going to save us from Wirth's law or anything, I'm just trying to give people context on what a huge jump it has been.
Having written significant pieces of code in javascript over the last 13 years, I've benefitted massively from those speed increases, and while I'm aware of a number of reasons that they have occurred (including but not limited to the v8 engine - I remember reading excitedly about tamarin, tracemonkey and the like), I don't think it's silly to point out the sheer magnitude of the improvement.
I'm not trying to say that JS is going to save us from Wirth's law or anything, I'm just trying to give people context on what a huge jump it has been.
Okay, but we can always replace "slow" by "slower than" and in a desktop environment (which the article is about), we could still compile C++ code to run natively and outperform JavaScript any day. The whole brouhaha about JavaScript being fast stemmed from it suddenly not being 10 times slower than native code in benchmarks. But it's still slower.
By using JavaScript you are, out of the box, sacrificing about 20% of your performance for the comfort of using it. In some cases, maybe only 10%. In others 50%.
I can totally understand how that's a trade-off one is willing to make in many cases. But for desktop apps, I kinda want them to run at full speed. Like, a 0.2 second delay can get annoying if it comes at the wrong time or stacks with something else. And somehow, you can feel that in many hyper-modern apps that are so many layers removed from the hardware, the devs probably don't even know where it touches it.
By using JavaScript you are, out of the box, sacrificing about 20% of your performance for the comfort of using it. In some cases, maybe only 10%. In others 50%.
I can totally understand how that's a trade-off one is willing to make in many cases. But for desktop apps, I kinda want them to run at full speed. Like, a 0.2 second delay can get annoying if it comes at the wrong time or stacks with something else. And somehow, you can feel that in many hyper-modern apps that are so many layers removed from the hardware, the devs probably don't even know where it touches it.
> Most people do not use JavaScript since it is useful. They use it since it is the only option available on the browser.
You're not contradicting what you are replying to. People are using Javascript because it's the only option, but it is useful to have a lingua franca.
I just wish that lingua franca wasn't Javascript.
You're not contradicting what you are replying to. People are using Javascript because it's the only option, but it is useful to have a lingua franca.
I just wish that lingua franca wasn't Javascript.
It's very far from the only option server-side (node), but a lot of people are using it there... and on the desktop (various native tooling options, electron, etc), and in mobile apps (react native, nativescript, cordova).
I know someone who's wished for "one language to rule them all" for a long time and wants/wanted that to be Visual Basic... It's a matter of perspective as much as anything else.
JS can be a very beautiful/expressive language... and mocking some of the corner cases of coercion doesn't really help the argument. JS started as a language for input validation first... it works in a way that input validation passes/fails very cleanly. It makes it a great transport/middle-man language actually.
I know someone who's wished for "one language to rule them all" for a long time and wants/wanted that to be Visual Basic... It's a matter of perspective as much as anything else.
JS can be a very beautiful/expressive language... and mocking some of the corner cases of coercion doesn't really help the argument. JS started as a language for input validation first... it works in a way that input validation passes/fails very cleanly. It makes it a great transport/middle-man language actually.
I agree with the first part.
The issues of: "utility of lingua franca" and "ubiquity of Javascript" are orthogonal issues.
It seems everyone agrees that Javascript would not have been the first choice of language. There is no short argument there, you have to go out and try at least one other language and compare them.
However, on the second question, I don't see why it is useful to have a lingua franca.
Multiple languages arise out of multiple needs. You want a superfast language for your OS, you want a quick high level language for quickly examining data, you want a language that describes visuals and so forth.
What are the benefits of a lingua franca for the internet, or any other domain? They still get to exchange data in an agreed upon format.
The issues of: "utility of lingua franca" and "ubiquity of Javascript" are orthogonal issues.
It seems everyone agrees that Javascript would not have been the first choice of language. There is no short argument there, you have to go out and try at least one other language and compare them.
However, on the second question, I don't see why it is useful to have a lingua franca.
Multiple languages arise out of multiple needs. You want a superfast language for your OS, you want a quick high level language for quickly examining data, you want a language that describes visuals and so forth.
What are the benefits of a lingua franca for the internet, or any other domain? They still get to exchange data in an agreed upon format.
Because all of the languages supported by the browser have to interact with the DOM. DOM memory management is incredibly tricky: it will not do to just have "an agreed upon format" to exchange data between such languages. You need all the languages to participate in a single garbage collection regime and to have semantics for interoperability at the object level between all of them, which is a very difficult problem.
Even getting interoperability between JS and C++—what the browsers do to implement the DOM—has been exceptionally difficult, with innumerable security vulnerabilities resulting from this.
Even getting interoperability between JS and C++—what the browsers do to implement the DOM—has been exceptionally difficult, with innumerable security vulnerabilities resulting from this.
When I said "agreed upon format" I was thinking of something like JSON to talking to the server. I didn't think of various tabs on a browser having to interact.
You probably know more about how the browser works than I do, but I think I see what you're saying.
Suppose we implemented a browser that can allows front ends coded in RUST. In my mind, the browser just gives the RUST app its own tab, with its own memory and so forth.
I am not proposing mixing up languages for the a given front end, or for components within an application or anything. Not because I think that would be wrong, but because I haven't thought it through.
You probably know more about how the browser works than I do, but I think I see what you're saying.
Suppose we implemented a browser that can allows front ends coded in RUST. In my mind, the browser just gives the RUST app its own tab, with its own memory and so forth.
I am not proposing mixing up languages for the a given front end, or for components within an application or anything. Not because I think that would be wrong, but because I haven't thought it through.
> I just wish that lingua franca wasn't Javascript.
Why?
Just because undefined is not a function [0]?
[0] https://twitter.com/vikasgorur/status/744204277745254400
Why?
Just because undefined is not a function [0]?
[0] https://twitter.com/vikasgorur/status/744204277745254400
Also, when it comes to languages. I rather have one language to be agreed upon, and to have small, gradual improvements to that language while keeping the world standard and simple. In case of JavaScript the improvement is strong typing.
If you want strong(er) typing, just create with TypeScript or flow... I don't see nearly the value in it that you seem to.
> Learn something else.
No. I've never understood the anti-[language] viewpoint. Wouldn't it be great to have every language available in every ecosystem? Why bother with web assembly when we could just replace JS with python because that's what _I_ want.
[1] Let's be honest, This is every language. There are some stupid, stupid, STUPID parts of JS that everyone enjoys pointing out. And... since everyone points them out, nobody actually uses them.
[2] It happened and they changed the root cause within a week. I would view that as a pretty good ecosystem. Now take a look at python 2 vs 3. Almost 8 years later, and we still need: http://py3readiness.org/
[3] Every language.
[4] Just because people talk loudly about something, doesn't mean most people use it. 90% of the internet still runs on jQuery: http://trends.builtwith.com/javascript/javascript-library
No. I've never understood the anti-[language] viewpoint. Wouldn't it be great to have every language available in every ecosystem? Why bother with web assembly when we could just replace JS with python because that's what _I_ want.
[1] Let's be honest, This is every language. There are some stupid, stupid, STUPID parts of JS that everyone enjoys pointing out. And... since everyone points them out, nobody actually uses them.
[2] It happened and they changed the root cause within a week. I would view that as a pretty good ecosystem. Now take a look at python 2 vs 3. Almost 8 years later, and we still need: http://py3readiness.org/
[3] Every language.
[4] Just because people talk loudly about something, doesn't mean most people use it. 90% of the internet still runs on jQuery: http://trends.builtwith.com/javascript/javascript-library
I've spend a decade in c and c++, another in Java. I've now moved to Javascript and I love everything about it. Well not everything, I don't really like the whole NPM and millions of dependencies. I also don't like react and angular. But JS is so big, there's enough other stuff I do like.
You see, you don't have to like everything about it to enjoy working with it. I pick the stuff I care about and put my positive energy towards it, instead of my negative energy towards the other. You should try it. You're free to make whatever tools you use right now as easy to use and as quick to learn. Maybe if you try hard enough, us Javascripters might come join your side.
You see, you don't have to like everything about it to enjoy working with it. I pick the stuff I care about and put my positive energy towards it, instead of my negative energy towards the other. You should try it. You're free to make whatever tools you use right now as easy to use and as quick to learn. Maybe if you try hard enough, us Javascripters might come join your side.
People just hate all old and we'll used languages. You hear javascript, java, and c++ getting hated on all the time. I feel like as languages age people just find all the stuff they hate about it. That being said javascript was a uniquely poorly designed language that only gained popularity by people being forced to use it. At least the modern versions of it seem to be have fixed many problems.
For [1] many languages have "wat"'s. Also, the leap from "wat"'s to "absolutely bad programming" is a jump in reasoning. You can be a poor hacker in any language.
For [2] and [4], they are issues with the ecosystem, which I suppose it related but isn't strictly js, ie., you don't have to use React (shock). For npm, at least that issue has been addressed.
[3] is a social issue...it happens in many places. Can you claim that the university system is flawed due to similar attitudes of students who attend university?
For [2] and [4], they are issues with the ecosystem, which I suppose it related but isn't strictly js, ie., you don't have to use React (shock). For npm, at least that issue has been addressed.
[3] is a social issue...it happens in many places. Can you claim that the university system is flawed due to similar attitudes of students who attend university?
I'm a fan of "You can write COBOL code in just about every language." I saw a pretty large VB5/6 app that was entirely styled like a COBOL app.. it was hideous to debug/use/follow, but it can be done... After that, I decided a lot of the time, it isn't the language that's the problem most of the time.
[2], [3] and [4] I would argue are not problems specific to JS, but are problems with "lingua francas" in general. Ubiquity, massive massive general popularity and low barriers of entry for a language will lead to an ecosystem dominated by the NIH and overengineering of eager & inexperienced programmers, and by egos. This would occur were any language put in JS' position.
The challenge is navigating such ecosystems in a selective and informed way, which is a programming skill in itself.
The challenge is navigating such ecosystems in a selective and informed way, which is a programming skill in itself.
> Slightly tangentially though, I wonder if we really really put our mind to it, will we be able to just kill JavaScript ?
Humans that "really wanted to" landed on the Moon, brought hundreds of millions of people out of poverty, cured polio and brought down Communism.
The real problem is that you'll never get that many people to agree on something like killing Javascript and creating something radically superior (whatever that is). The web ecosystem is proof of the highest level of agreement possible on a wide scale.
And to be honest, what's the alternative? If Javascript dies, we won't get a great new common programming language. We'll get 10 mostly walled gardens with barely any compatibility. Unix vendor wars, post-web edition.
Humans that "really wanted to" landed on the Moon, brought hundreds of millions of people out of poverty, cured polio and brought down Communism.
The real problem is that you'll never get that many people to agree on something like killing Javascript and creating something radically superior (whatever that is). The web ecosystem is proof of the highest level of agreement possible on a wide scale.
And to be honest, what's the alternative? If Javascript dies, we won't get a great new common programming language. We'll get 10 mostly walled gardens with barely any compatibility. Unix vendor wars, post-web edition.
Here's the thing -- we didn't need to get the moon's participation. A moon shot is an application of physics, with some concern for weight tradeoffs and fuel energy density and the like. It's not a coordination problem.
>Most people do not use JavaScript since it is useful. They >use it since it is the only option available on the browser.
Maybe it's the only option available on the browser because it is useful to have a lingua franca for the web.
Maybe it's the only option available on the browser because it is useful to have a lingua franca for the web.
simula67, are you aware that the website (http://jojiantony.xyz) in your profile goes to an Apple phishing website?
For a long time, there was no political will to kill Javascript; there was barely enough political will to reform it -- see the Eich vs. Wilson debate [1].
Now that JS has seen 2 new versions in 2 years, momentum has picked up and it's keeping up with the times much more so than in the late 2000s when its flaws were glaring and apparent. One of the interesting side-effects of the extra effort going into the web platform is the 'wasm' effort [2] which could replace Javascript at some point -- yes, the usual caveats about GC and DOM apply, but they're coming [3][4].
Though the political line is that wasm isn't intended to replace Javascript, once it attains feature parity (like it's headed towards), it'll be trivial to do so, regardless of what the designers intend. When that time comes, JS will probably still be used as a written language, but wasm will become the new compilation target.
[1] https://en.wikipedia.org/wiki/ECMAScript#4th_Edition_.28aban...
[2] https://webassembly.github.io/
[3] https://github.com/WebAssembly/design/issues/219
[4] https://github.com/WebAssembly/design/blob/master/GC.md
Now that JS has seen 2 new versions in 2 years, momentum has picked up and it's keeping up with the times much more so than in the late 2000s when its flaws were glaring and apparent. One of the interesting side-effects of the extra effort going into the web platform is the 'wasm' effort [2] which could replace Javascript at some point -- yes, the usual caveats about GC and DOM apply, but they're coming [3][4].
Though the political line is that wasm isn't intended to replace Javascript, once it attains feature parity (like it's headed towards), it'll be trivial to do so, regardless of what the designers intend. When that time comes, JS will probably still be used as a written language, but wasm will become the new compilation target.
[1] https://en.wikipedia.org/wiki/ECMAScript#4th_Edition_.28aban...
[2] https://webassembly.github.io/
[3] https://github.com/WebAssembly/design/issues/219
[4] https://github.com/WebAssembly/design/blob/master/GC.md
> I mean, I am sure that there are people out there making a living on JavaScript, but please, take one for the team. Learn something else. I hear it is a hot market for developers.
Where I live JS jobs are some of the highest paying actually. If anything people are moving to it.
Where I live JS jobs are some of the highest paying actually. If anything people are moving to it.
> "Slightly tangentially though, I wonder if we really really put our mind to it, will we be able to just kill JavaScript ?"
Kill maybe too string a word (languages that reach the level of usage of JavaScript tend to stick around regardless of what's currently popular), but for me the main promise of WebAssembly is to allow web browsers to branch out from JavaScript as the only native programming language of the web (as well as improving performance).
Kill maybe too string a word (languages that reach the level of usage of JavaScript tend to stick around regardless of what's currently popular), but for me the main promise of WebAssembly is to allow web browsers to branch out from JavaScript as the only native programming language of the web (as well as improving performance).
> > It turns out it’s useful to have a lingua franca for the web.
> No, I don't think so. Most people do not use JavaScript since it is useful. They use it since it is the only option available on the browser.
Are you not contradicting yourself here? If people use JS only because it's what's on the browser, then it's only because people see value in ... having a lingua franca for the web.
> No, I don't think so. Most people do not use JavaScript since it is useful. They use it since it is the only option available on the browser.
Are you not contradicting yourself here? If people use JS only because it's what's on the browser, then it's only because people see value in ... having a lingua franca for the web.
I smell an agenda in the comment from the person with the username "simula67"... (this is a joke, by the way)...
The salient points of the article:
- People are stuffing websites into Electron and packaging it as a native application
- HTML/CSS/JS is considered 'hackable' because it's widely understood by today's semi-power-user audience
Although the article doesn't say it, this seems to imply that:
- Full-native development unique on each platform is considered too much effort, when you can get a cross-platform app with Electron
- Other platforms are not very 'hackable'; why is this?
Is this purely because JS has a higher mindshare and marketshare than [preferred platform language] on [preferred platform toolkit] on [preferred platform], or do HTML/CSS/JS applications actually tend to hit a sweet spot in terms of separation of presentation, view logic, business logic? Or is it about the view-understand-edit-deploy lifecycle being easier with HTML/JS apps?
- People are stuffing websites into Electron and packaging it as a native application
- HTML/CSS/JS is considered 'hackable' because it's widely understood by today's semi-power-user audience
Although the article doesn't say it, this seems to imply that:
- Full-native development unique on each platform is considered too much effort, when you can get a cross-platform app with Electron
- Other platforms are not very 'hackable'; why is this?
Is this purely because JS has a higher mindshare and marketshare than [preferred platform language] on [preferred platform toolkit] on [preferred platform], or do HTML/CSS/JS applications actually tend to hit a sweet spot in terms of separation of presentation, view logic, business logic? Or is it about the view-understand-edit-deploy lifecycle being easier with HTML/JS apps?
All of the above. If your application can be designed as a web application, you can use responsive designs and progressive enhancement techniques to create an experience that works across any platform with a web browser - with one code base. This is a pretty amazing thing, and for various business-related reasons this may seem like the right move.
The only progressive enhancement today's generation of web developers is capable of is showing a blank page if JS is turned off. Stop lying to yourselves that you care about usability or accessibility.
This whole thing just stinks of forcing the browser to be a (terrible, poorly functioning, and inconsistent) abstraction over the OS. The browser/webapp model of application development is just awful.
I don't think anyone would argue that web development is perfect. What is? But, thanks to the ubiquity of the web browser, it is the only way to create a common user interface across any platform. Given that context I am grateful to have it.
Common user interface across any browser (platform) that supports it, you mean. Like any other language.
> HTML/CSS/JS is considered 'hackable' because it's widely understood by today's semi-power-user audience
I think that's related to the high fault-tolerance in Javascript. A good developer is good in any language, so she can work with Javascript. A beginner or even a bad developer can make things happen in Javascript, when that is not always possible in other languages. So the entry point level is so low that a lot of people is using it.
> Other platforms are not very 'hackable'; why is this?
I prefer strong typed languages. I use TypeScript when I have to do some JS work as it is easier to maintain in the long term. But that means that you need to know what you are doing before starting to do anything. Compile, fix errors, repeat.
I can see that for starters JS is more fun and "hackable", as it was BASIC for me when I started.
I think that's related to the high fault-tolerance in Javascript. A good developer is good in any language, so she can work with Javascript. A beginner or even a bad developer can make things happen in Javascript, when that is not always possible in other languages. So the entry point level is so low that a lot of people is using it.
> Other platforms are not very 'hackable'; why is this?
I prefer strong typed languages. I use TypeScript when I have to do some JS work as it is easier to maintain in the long term. But that means that you need to know what you are doing before starting to do anything. Compile, fix errors, repeat.
I can see that for starters JS is more fun and "hackable", as it was BASIC for me when I started.
>> > HTML/CSS/JS is considered 'hackable' because it's widely understood by today's semi-power-user audience
> I think that's related to the high fault-tolerance in Javascript.
Also, in Electron apps you can access the Chromium Dev Tools directly in the app (unless the app author has disabled it). Chromium's Dev Tools are pretty much the gold-standard for hacking during runtime.
> I think that's related to the high fault-tolerance in Javascript.
Also, in Electron apps you can access the Chromium Dev Tools directly in the app (unless the app author has disabled it). Chromium's Dev Tools are pretty much the gold-standard for hacking during runtime.
> Chromium's Dev Tools are pretty much the gold-standard for hacking during runtime
... if you don't include any IDE with a built-in debugger.
... if you don't include any IDE with a built-in debugger.
Chromium dev tools essentially IS an IDE with a built-in debugger. You can set breakpoints, step over/into/out of code, monitor network requests, view/edit the DOM tree, edit CSS in real time... For some code, you can even edit it while it's executing. Plus it exposes a REPL at window scope.
SmallTalk and Lisp would have something to say about that.
I can assure you that a bad developer can make things happen in any language. And it will look and behave like shit in all of them. There is no language that makes a developer write good code by magic.
There are languages where non-developers can make SOMETHING happen (like make the monkey dance[1]). There are languages where non-programmers can't -- you have to be SOME kind of programmer, good or bad, to make C do something other than look at you unkindly.
1) http://programmers.stackexchange.com/questions/221615/why-do...
1) http://programmers.stackexchange.com/questions/221615/why-do...
I think it's the mixture of both. Editing something, pressing f5 and watching new changes getting into your webpage is really great, and a form of instant gratification. This workflow will always be better than for example restarting jetty web server to reload some servlet... Also when you have everything packaged inside you don't worry about runtime libraries. That's another headache in native app deployments. And the third is great ecosystem of libraries, editors, tutorials, snippets, etc. Low entry barrier makes it easy to quickly adopt.
What makes JS more "hackable"? Someone find that cartoon about the gaunt-looking guy and the laid-back kid when the girl asks them to hold her coffee and link it [edit: http://i.imgur.com/76Wtthy.jpg ].
...Because it gets the hell out of they way and holds your coffee for you and doesn't slap it out of your hand and throw a tantrum because it was actually a medium coffee...and it gives you the simplest no-BS object/array literals you can get...IMO opinion everyone wailing and beating their chest bemoaning the fact that JS got where it is fails to understand that it got there because it the "UX" of coding JS is just a lot more pleasant - and you can treat it as a compile target and do your work in a more type-obsessed thing like Typescript if that's your cup of tea without imposing on the underlying "hackability" of the language.
...Because it gets the hell out of they way and holds your coffee for you and doesn't slap it out of your hand and throw a tantrum because it was actually a medium coffee...and it gives you the simplest no-BS object/array literals you can get...IMO opinion everyone wailing and beating their chest bemoaning the fact that JS got where it is fails to understand that it got there because it the "UX" of coding JS is just a lot more pleasant - and you can treat it as a compile target and do your work in a more type-obsessed thing like Typescript if that's your cup of tea without imposing on the underlying "hackability" of the language.
> it gives you the simplest no-BS object/array literals you can get
I really don't think that:
I really don't think that:
{
"foo": "bar",
"baz": ["quux", 1, true]
}
((foo bar)
(baz (quux 1 true)))
Question: Can s-expression list-of-lists really be used to represent an unordered map when it comes to operations like equality? Or rather, does one simply use expectations/context to compare this object to, say
[["foo", "bar"], ["baz", ["quuz", 1, true]]]
> Question: Can s-expression list-of-lists really be used to represent an unordered map when it comes to operations like equality?
With the right predicates, anything is possible grin
I think that context unavoidable: one can't just read a JSON value into a generic data structure, or even into a typed structure: one has to apply the types of one's business logic (e.g. 'user-id' must not only be a string, but a string beginning with either 'E' or 'C'). In that context (pun intended), then it makes sense for equality comparisons to be at the business-object layer, not at the freshly-deserialised JSON object layer.
With the right predicates, anything is possible grin
I think that context unavoidable: one can't just read a JSON value into a generic data structure, or even into a typed structure: one has to apply the types of one's business logic (e.g. 'user-id' must not only be a string, but a string beginning with either 'E' or 'C'). In that context (pun intended), then it makes sense for equality comparisons to be at the business-object layer, not at the freshly-deserialised JSON object layer.
That does look nice. Is that, LISP? To my eye, they look roughly equivalent, though - and a lot of what I consider the "No-BS object system" occurs after the literal is declared - adding and manipulating properties, etc.
> Is that, LISP?
Well, S-expressions, which can be used for Lisp code, but can also just be used for plain data.
> a lot of what I consider the "No-BS object system" occurs after the literal is declared - adding and manipulating properties, etc.
Yeah, it's definitely convenient to use, even more so than Python's objects. I prefer a stronger type system for my own software though.
Well, S-expressions, which can be used for Lisp code, but can also just be used for plain data.
> a lot of what I consider the "No-BS object system" occurs after the literal is declared - adding and manipulating properties, etc.
Yeah, it's definitely convenient to use, even more so than Python's objects. I prefer a stronger type system for my own software though.
The bottom is definitely ambiguous.
What's ambiguous? If you don't like that it's using a list to represent a map, you could always use:
(map (foo bar)
(baz (quux 1 true)))
Typescript is sufficiently close to JavaScript that it doesn't really feel like it's treating JS as some invisibly underlying assembly-like layer.
In practice, you can use as much or as little typing as you want, and the compiler will occasionally tell you "I think you're doing something dangerous here", but even then you're only one <any> away from ignoring its generally good advice (or more sanely, you would annotate the ambiguous bits a bit better so typescript understands you really meant to do that.)
But otherwise, all the usual js hacks still very much apply.
Anyway, that's why typescript is my cup of tea|coffee.
In practice, you can use as much or as little typing as you want, and the compiler will occasionally tell you "I think you're doing something dangerous here", but even then you're only one <any> away from ignoring its generally good advice (or more sanely, you would annotate the ambiguous bits a bit better so typescript understands you really meant to do that.)
But otherwise, all the usual js hacks still very much apply.
Anyway, that's why typescript is my cup of tea|coffee.
Hmm not convinced.
Is it pleasant UX that you can put petrol in your diesel car because the nozzle fits? Would it be pleasant UX to have your bank let someone withdraw money from your account without ID? Bleach bottle with no safety cap?
Also the laid back kid of JS will throw a tantrum if the coffee is not a coffee. He'll throw the tantrum at your customer though (at runtime), not your developer (at compiler time). Which arguably is a good UX for coding but not the bottom line.
Is it pleasant UX that you can put petrol in your diesel car because the nozzle fits? Would it be pleasant UX to have your bank let someone withdraw money from your account without ID? Bleach bottle with no safety cap?
Also the laid back kid of JS will throw a tantrum if the coffee is not a coffee. He'll throw the tantrum at your customer though (at runtime), not your developer (at compiler time). Which arguably is a good UX for coding but not the bottom line.
It would be pleasant if your engine didn't care whether you put gas or diesel in it and just ran. I think that's the point made in the cartoon.
I like that the kid just holds the cup and pours it when I tell him to. If I wanted him to pour coffee and gave him a cup of beer, I'm ok saying that's my fault. I'd still rather have the kid. Having a guy that only accepts "Large cups of coffee" is necessary at lower levels (c), but keep it out of my scripting language.
I like that the kid just holds the cup and pours it when I tell him to. If I wanted him to pour coffee and gave him a cup of beer, I'm ok saying that's my fault. I'd still rather have the kid. Having a guy that only accepts "Large cups of coffee" is necessary at lower levels (c), but keep it out of my scripting language.
In this analogy I'd say the engine cares in both JS and Java.
In Java you get an annoying compiler error.
In JS you get a trashed engine at runtime.
In Java you get an annoying compiler error.
In JS you get a trashed engine at runtime.
To continue the analogy what happens when you accidentally pass him a cup of bleach?
Considering the variety of fuel sources a diesel engine can use (oil, deisel, etc), I'd say it is pretty useful... ;-)
Yeah, and good luck dealing with that remote API that now gives you an extra field in the JSON or XML, and your compiled client in a few thousand workstations needs to be updated and redeployed because of said fit.
Yeah, and good luck dealing with that remote API that now gives you an extra field in the JSON or XML, and your compiled client in a few thousand workstations needs to be updated and redeployed because of said fit.
> Yeah, and good luck dealing with that remote API that now gives you an extra field in the JSON or XML
Java C# and every other decent typed language has good serialization and deserialization support. The extra field poses no problem.
Java C# and every other decent typed language has good serialization and deserialization support. The extra field poses no problem.
I've had to consume Java generated wsdl in C#, having response types of "Object" from the Java side, meaning the .Net side has no properties on the responses from those methods, I'd have to disagree...
Nothing to do with static vs dynamic typing. Just get Java and C# to talk in another protocol. How about JSON or vanilla XML
Yeah I find the "hackability" question really interesting. It is incredibly neat that I can hit a few keys in a browser and get an editable live source of what I'm looking at which is, to some extent, declarative and easily mappable from source to output. Yes, this is less true as more sites rely heavily on minified javascript for all of their implementation, or incomprehensible (to me) css that hides or moves things around in non-obvious ways, but it still mostly works. I definitely can't think of any commonly used native apps that are so easy to inspect and edit! Interestingly, though, I think you lose all that with something like Electron. At least, I don't know how to do that in eg. the native Slack client.
> "Full-native development unique on each platform is considered too much effort, when you can get a cross-platform app with Electron"
Yes, it's this. Full native development is awful since every platform is completely different, and other cross-platform solutions like Qt are a bit behind the web in terms of modern look and feel and developer base.
But Electron is also awful, since a hello world app uses 100mb of RAM.
Desktop GUI app development is horrible... meaning it's slightly worse than mobile GUI app development. GUI development in general is a horrid ghetto where your choice is between bad and completely proprietary.
Yes, it's this. Full native development is awful since every platform is completely different, and other cross-platform solutions like Qt are a bit behind the web in terms of modern look and feel and developer base.
But Electron is also awful, since a hello world app uses 100mb of RAM.
Desktop GUI app development is horrible... meaning it's slightly worse than mobile GUI app development. GUI development in general is a horrid ghetto where your choice is between bad and completely proprietary.
[deleted]
"But Electron is also awful, since a hello world app uses 100mb of RAM."
Is it that awful, though? Most computers come with 4-16GB of RAM.
Is it that awful, though? Most computers come with 4-16GB of RAM.
Yes, that is not just terrible it is embarrassing.
Yes - some of us want to use our multitasking systems for multitasking.
How many tabs do we have opened in our browsers? I rarely have less than a dozen. I think it's fair to say that "browser as a runtime" isn't incompatible with multitasking.
You can say that it would be better to share a common Electron instance, but it's not an argument against the idea of using web technologies for desktop programming.
You can say that it would be better to share a common Electron instance, but it's not an argument against the idea of using web technologies for desktop programming.
Yes, if hello worlds uses that much then how much do complicated apps use?
I guess I believe it is common that if a platform becomes popular enough for developers - solutions will appear to allow them to reuse their knowledge in developing applications outside of their original target platform.
Furthermore in the attempt to woo developers from one popular platform to another a myriad of solutions will appear to allow the developer to move their existing tools, methods, and general knowledge from their comfortable and familiar platform onto the new one.
I'd suppose anyone that has more than 5+ years experience and has moved between at least two types of platforms can point to examples in their mind.
Personally I dislike this habit of using tooling to solve platform movement and escape the time constraints inherent in learning to develop for a new platform; I can however see the attraction, because, it really does ease time and effort in learning something new even if to provide this easing it acts a buffer to any deep understanding of the target platform.
Furthermore in the attempt to woo developers from one popular platform to another a myriad of solutions will appear to allow the developer to move their existing tools, methods, and general knowledge from their comfortable and familiar platform onto the new one.
I'd suppose anyone that has more than 5+ years experience and has moved between at least two types of platforms can point to examples in their mind.
Personally I dislike this habit of using tooling to solve platform movement and escape the time constraints inherent in learning to develop for a new platform; I can however see the attraction, because, it really does ease time and effort in learning something new even if to provide this easing it acts a buffer to any deep understanding of the target platform.
There are more advantages than just not having to learn something new. There are really compelling reasons you might want to use the same code in some combination of: a web browser, web server, Windows app, Mac app, iOS app, and Android app.
For instance, when FB used React Native for building one of their ad manager apps, they had 87% code reuse between iOS and Android (https://twitter.com/brindelle/status/618114397098102785) The implications that has on a company's eng organization are huge.
Another example is the code sharing between client and server in Meteor. That has big implications too.
The main reason Javascript is winning as the lingua franca is that it's pretty much the only language you can use in a browser. The main alternatives are things that compile to JS, like Babel, TypeScript, and for a while Coffeescript and Dart were gaining traction too. If browsers could run, say, Python, I suspect you'd see more Python used in this way as well.
For instance, when FB used React Native for building one of their ad manager apps, they had 87% code reuse between iOS and Android (https://twitter.com/brindelle/status/618114397098102785) The implications that has on a company's eng organization are huge.
Another example is the code sharing between client and server in Meteor. That has big implications too.
The main reason Javascript is winning as the lingua franca is that it's pretty much the only language you can use in a browser. The main alternatives are things that compile to JS, like Babel, TypeScript, and for a while Coffeescript and Dart were gaining traction too. If browsers could run, say, Python, I suspect you'd see more Python used in this way as well.
>There are really compelling reasons you might want to use the same code in some combination of: a web browser, web server, Windows app, Mac app, iOS app, and Android app.
I agree, but it is my experience that this always comes with a downside that you don't know some of the platforms you are running on and there are deficiencies. The Native is better argument
I agree, but it is my experience that this always comes with a downside that you don't know some of the platforms you are running on and there are deficiencies. The Native is better argument
Part of it is also, custom looking UI, not confined to the platform widgets, is not easy to do on many of the desktop platform libraries. It is incredibly easy to do with HTML/CSS.
10 years ago everyone hated on java because it didn't look native. Now no one wants anything to look native.
There is no "View source" button for native applications, and you can not modify them and see the results immediately.
This is not true. Electron comes with the full suite of Chrome Dev Tools (CTRL-SHIFT-I is default when enabled). You can certainly achieve a live-coding experience with Electron[1].
[1]: one of many boilerplates - https://github.com/chentsulin/electron-react-boilerplate
[1]: one of many boilerplates - https://github.com/chentsulin/electron-react-boilerplate
Probably 90% of .NET/JVM apps, you can hitch a decompiler up to and "View Source".
Patching the byte code and having it run is a little tougher...
Patching the byte code and having it run is a little tougher...
JS is safe C with types and pointers stripped from the syntax.
I don't get why people don't understand its popularity.
HTML lets you put boxes on the screen and CSS lets you paint-by-number(id/name/selector).
If you aren't doing any of those things, I am very curious to know what exactly you are doing.
I don't get why people don't understand its popularity.
HTML lets you put boxes on the screen and CSS lets you paint-by-number(id/name/selector).
If you aren't doing any of those things, I am very curious to know what exactly you are doing.
JS is most definitely not safe C. It has a brace based syntax with if statements and for loops but other than those superficial similarities it's semantics are vastly different.
x += 2;
call(param);
data.key = cache[0];Just like PHP :-)
I think people hate the quirkiness of it and the dynamic typing.
I'm not an expert, but the memory required to render the seemingly simplest of interfaces in html/js/css in a browser today seems excessive. Some web sites bring a reasonably powered desktop to its knees. I'm not sure I want this problem on my desktop too. Though I guess this is just one step closer to having METAL. https://www.destroyallsoftware.com/talks/the-birth-and-death...
No one likes that, but
1) HTML/CSS/JS is sill the only truly cross-platform (mac/windows/linux/web/ios/android/etc.) UI platform/ecosystem in 2016, and it will probably stay that way in the foreseeable future because OS makers love their walled gardens.
2) An app's memory efficiency is not a top 10 priority of an average solo-or-small-team developer's concerns, because that's not what most users pay for.
Electron/NW.js apps will only become more common, so I hope things will improve with asm.js/webassembly/etc.
1) HTML/CSS/JS is sill the only truly cross-platform (mac/windows/linux/web/ios/android/etc.) UI platform/ecosystem in 2016, and it will probably stay that way in the foreseeable future because OS makers love their walled gardens.
2) An app's memory efficiency is not a top 10 priority of an average solo-or-small-team developer's concerns, because that's not what most users pay for.
Electron/NW.js apps will only become more common, so I hope things will improve with asm.js/webassembly/etc.
On point (1) you've kind of loaded the comparison by including web in that list...
It's a common business scenario: start out as a web app, then as business picks up let's start providing native apps.
Or the other way: start out with a native app on the platform we most care about + a web app for "access from anywhere".
Or the other way: start out with a native app on the platform we most care about + a web app for "access from anywhere".
It would be interesting to see the evolution of memory usage for the popular platform du jour from the earliest decades until today. My uneducated guess says it will be an exponential.
Python would like a word with you about point 1)
Well I have yet to see Python make a decent cross platform application on all of those platforms especially iOS and Android.
I love Python but people over state its benefits and effectiveness.
I love Python but people over state its benefits and effectiveness.
Python is wonderful for business logic and scientific computations. HTML/JavaScript is wonderful to make beautiful interactive user interfaces.
So at the moment, I am using PyQt/PySide and load my HTML/JavaScript/ReactJS GUI in a webview with a simple bridge object between my Python code and the JavaScript code.
As soon as I need native interactions with the file system, etc., I am using Python, which is robust and proven (and I am used to it). For example, if I need a dialog to save a file, I just use QFileDialog.
At the end, because of a clear separation between the GUI and the computation/system interactions with the bridge object, I just need a different bridge object to have everything running fully online.
One point is of course that I am not developing for phones and tablets, I package everything with pyinstaller for the good old desktop users.
So at the moment, I am using PyQt/PySide and load my HTML/JavaScript/ReactJS GUI in a webview with a simple bridge object between my Python code and the JavaScript code.
As soon as I need native interactions with the file system, etc., I am using Python, which is robust and proven (and I am used to it). For example, if I need a dialog to save a file, I just use QFileDialog.
At the end, because of a clear separation between the GUI and the computation/system interactions with the bridge object, I just need a different bridge object to have everything running fully online.
One point is of course that I am not developing for phones and tablets, I package everything with pyinstaller for the good old desktop users.
I use a network simulation software inside of lubuntu inside of a VirtualBox inside my Mac. VirtualBox is a stream of headaches, and you suffer a big performance hit. What I wouldn't give for the software to serve an http/css/js interface so that I could run it with docker or natively instead.
Make sure that the virtual machine has "paravirtualization interface: kvm" setting for linux guests, that the guest tools are installed and if you really use network, adapter type: virtio-net doesn't hurt. And also, that you have enough RAM. Then, virtual machines in VirtualBox are fine.
Thanks! Good samaritan :)
Honest question – how do you build cross-platform application UI in python?
I'm not familiar with the Python ecosystem but I imagine there are bidings for GTK, QT, or other UI toolkits. The same applies to most (popular) languages. The claim that HTML/CSS/JS is the "only" truly cross platform stack is simply not true.
The main hurdle that other languages faced was not having a native UI. For example, GTK on OSX or Windows did not feel native. Key bindings were often not native. Similar story with Java (was it Swing?).
The HTML/JS/CSS combo has exactly the same issue (it's not comparable to a native GUI - Cocoa or whatever it is.
The main hurdle that other languages faced was not having a native UI. For example, GTK on OSX or Windows did not feel native. Key bindings were often not native. Similar story with Java (was it Swing?).
The HTML/JS/CSS combo has exactly the same issue (it's not comparable to a native GUI - Cocoa or whatever it is.
> The main hurdle that other languages faced was not having a native UI.
Electron faces this same hurdle, but with a twist. It just doesn't care; it picks a rendering target (the web) and simply uses it everywhere. Perhaps that's the approach QT and others need to take as well: stop trying to match Apple's UI on Apple, and Windows' UI on Windows.
Electron faces this same hurdle, but with a twist. It just doesn't care; it picks a rendering target (the web) and simply uses it everywhere. Perhaps that's the approach QT and others need to take as well: stop trying to match Apple's UI on Apple, and Windows' UI on Windows.
> stop trying to match Apple's UI on Apple, and Windows' UI on Windows.
Great idea, but make sure it at least looks/feels good.
I remember Swing stuff from the late 90s and... IMO the primary issue wasn't so much that "it doesn't look like Windows" but that ... it was a very poor experience.
Copy/paste/keys - yeah, that's an annoyance, but if the UI is clean, friendly, easy to understand and be productive on, people can look past the differences of the native host OS. Swing (and GTK and others) really don't provide a 'better' UX (imo).
Great idea, but make sure it at least looks/feels good.
I remember Swing stuff from the late 90s and... IMO the primary issue wasn't so much that "it doesn't look like Windows" but that ... it was a very poor experience.
Copy/paste/keys - yeah, that's an annoyance, but if the UI is clean, friendly, easy to understand and be productive on, people can look past the differences of the native host OS. Swing (and GTK and others) really don't provide a 'better' UX (imo).
Kivy.
Python on iOS?
Python can work on desktop, but it's solutions for mobile are iffy at best.
Java as well for basically anything but iOS.
C# might even cover that now.
C# might even cover that now.
Xamarin, I reckon?[1]
[1]: https://www.xamarin.com/
[1]: https://www.xamarin.com/
There's also Qt but they have been moving in the web direction too.
I feel your pain. My first computer had 4K of RAM; my second had 48K; my third, 640K. I learned to work small. It pains me to see the equivalent of Hello World taking up untold MB.
But when I think about software as a business rather than an art, I have to concede that it's a very rare circumstance where RAM efficiency matters as much as I'd like. Note the way the cost of memory has declined:
http://www.jcmit.com/mem2015.htm
Watches now have 100,000 times the RAM that I started with. Costs are dropping by 1-2 orders of magnitude per decade. Something that is absurdly wasteful now could well be economically reasonable very soon.
But when I think about software as a business rather than an art, I have to concede that it's a very rare circumstance where RAM efficiency matters as much as I'd like. Note the way the cost of memory has declined:
http://www.jcmit.com/mem2015.htm
Watches now have 100,000 times the RAM that I started with. Costs are dropping by 1-2 orders of magnitude per decade. Something that is absurdly wasteful now could well be economically reasonable very soon.
Memory isn't the issue to me. Latency is.
Most of the applications I work with today do a lot, that's true, but their UI latency is often worse than it was on my 7.16Mz M68000 Amiga 500, and other things as well are just slow.
I've mentioned here several times in the past that on my laptop I can "boot" Linux-hosted AROS (so the problem is not the Linux kernel, nor X) with a custom startup script to boot it straight into a full featured, scriptable text editor in less time than it takes to start Emacs.
I'm sure it's possible to tune my Emacs setup (for example, I found out by a fluke, that the default Emacs setup on debian will wait for a DNS request to complete or time out before it starts - break your DNS setup and Emacs will hang for ages) or pick another editor (many of the other ones I've tried are either just as slow or feature-limited compared to the Amiga editor in question - FrexxEd, co-written by the same guy that started curl), but the point is that we've come to accept the kind of slow startup and UI latency that was unacceptable back then.
E.g. people spent weeks tuning and trimming AmigaOS commands to make them the smallest possible so we could make as many of them as possible RAM resident to avoid the tiny fractions of a second it'd take the load-time linker to load them.
I'm happy we don't need to think that much about the RAM any more. But we do need to think about the latency.
There's the attitude that we should just throw servers at this instead of developer time. That's fine when you can compensate by e.g. throwing more RAM in and/or a program is run relatively rarely or where paying for a beefier server in some data centre can achieve the same performance. But it's not true when latency grows into user noticeable levels because you can't get high enough single-core performance, and that program is run a lot.
Most of the applications I work with today do a lot, that's true, but their UI latency is often worse than it was on my 7.16Mz M68000 Amiga 500, and other things as well are just slow.
I've mentioned here several times in the past that on my laptop I can "boot" Linux-hosted AROS (so the problem is not the Linux kernel, nor X) with a custom startup script to boot it straight into a full featured, scriptable text editor in less time than it takes to start Emacs.
I'm sure it's possible to tune my Emacs setup (for example, I found out by a fluke, that the default Emacs setup on debian will wait for a DNS request to complete or time out before it starts - break your DNS setup and Emacs will hang for ages) or pick another editor (many of the other ones I've tried are either just as slow or feature-limited compared to the Amiga editor in question - FrexxEd, co-written by the same guy that started curl), but the point is that we've come to accept the kind of slow startup and UI latency that was unacceptable back then.
E.g. people spent weeks tuning and trimming AmigaOS commands to make them the smallest possible so we could make as many of them as possible RAM resident to avoid the tiny fractions of a second it'd take the load-time linker to load them.
I'm happy we don't need to think that much about the RAM any more. But we do need to think about the latency.
There's the attitude that we should just throw servers at this instead of developer time. That's fine when you can compensate by e.g. throwing more RAM in and/or a program is run relatively rarely or where paying for a beefier server in some data centre can achieve the same performance. But it's not true when latency grows into user noticeable levels because you can't get high enough single-core performance, and that program is run a lot.
I don't disagree. I am certainly frustrated every time my phone feel sluggish, which is several times a day.
On the other hand, I've been frustrated with the slowness of computers for a long time. CPU speed, RAM, disk, everything has gotten way better. But I'm still just about as irritated, and I suspect that things are just about as sluggish.
Again, I think it's an economic equilibrium. Things are fast enough that most people buy them; those of us who want things faster aren't numerous to outvote those who want fancier features or cooler UI bling instead.
I hope this changes, but I'm not holding my breath.
On the other hand, I've been frustrated with the slowness of computers for a long time. CPU speed, RAM, disk, everything has gotten way better. But I'm still just about as irritated, and I suspect that things are just about as sluggish.
Again, I think it's an economic equilibrium. Things are fast enough that most people buy them; those of us who want things faster aren't numerous to outvote those who want fancier features or cooler UI bling instead.
I hope this changes, but I'm not holding my breath.
The weight still hurts the user experience. All that RAM still has to get written to disk for sleep/hibernate, and loading it back from disk is in the critical path of wake from that sleep. It still fills up CPU caches, which keeps them from running at maximal efficiency (both speed-wise and power-wise).
Extra weight will always matter for people who want to deliver first-rate user experiences.
Extra weight will always matter for people who want to deliver first-rate user experiences.
Poorly written websites can bring a desktop PC to its knees, but so can a poorly written native application. That isn't an argument against leveraging web technology so much as an argument in favour of well written applications. And at least with a chromeless-browser-pretending-to-be-application you have the protection of the browser process sandbox so an app that goes awry isn't going to take your computer down that badly.
> Poorly written websites can bring a desktop PC to its knees, but so can a poorly written native application.
Even well-written Web applications tend to use more system resources than their well-written desktop counterparts. A few days ago, I was surprised to find that Chromium was using 6 GB of RAM, while all other processes combined (including three Emacs instances, running fancy modes) were using just 1GB. And, no, I wasn't playing browser games or doing anything fancy in Chromium: just viewing text and images.
> And at least with a chromeless-browser-pretending-to-be-application you have the protection of the browser process sandbox so an app that goes awry isn't going to take your computer down that badly.
It would be much better to use programs that don't need to run in a sandbox in the first place. (To be fair, OS-enforced memory protection can be considered a kind of sandboxing too.)
Even well-written Web applications tend to use more system resources than their well-written desktop counterparts. A few days ago, I was surprised to find that Chromium was using 6 GB of RAM, while all other processes combined (including three Emacs instances, running fancy modes) were using just 1GB. And, no, I wasn't playing browser games or doing anything fancy in Chromium: just viewing text and images.
> And at least with a chromeless-browser-pretending-to-be-application you have the protection of the browser process sandbox so an app that goes awry isn't going to take your computer down that badly.
It would be much better to use programs that don't need to run in a sandbox in the first place. (To be fair, OS-enforced memory protection can be considered a kind of sandboxing too.)
> That isn't an argument against leveraging web technology so much as an argument in favour of well written applications
The difference is there is very little room for optimisation in most javascript runtimes. They don't support multi-threading and the memory is impossible to manage. "Lower" level languages always allow better performance tweaking when necessary. Javascript allows next to none. You can't tell javascript :"Give me an array of 10 elements", or "give me a integer of that length". So no "headroom" for performances with Javascript.
The difference is there is very little room for optimisation in most javascript runtimes. They don't support multi-threading and the memory is impossible to manage. "Lower" level languages always allow better performance tweaking when necessary. Javascript allows next to none. You can't tell javascript :"Give me an array of 10 elements", or "give me a integer of that length". So no "headroom" for performances with Javascript.
> They don't support multi-threading
Yes, they do, via Web Workers. They just don't support multithreading at the level of concurrent access to the DOM, and they don't support shared memory. Very few native libraries support concurrent access to UI widgets, and not many native applications make heavy use of shared memory for compute either. (Most native applications don't have heavy compute needs in the first place…)
> Give me an array of 10 elements
new Array(10)?
> give me a integer of that length
Uint8Array, Uint16Array, Uint32Array?
Yes, they do, via Web Workers. They just don't support multithreading at the level of concurrent access to the DOM, and they don't support shared memory. Very few native libraries support concurrent access to UI widgets, and not many native applications make heavy use of shared memory for compute either. (Most native applications don't have heavy compute needs in the first place…)
> Give me an array of 10 elements
new Array(10)?
> give me a integer of that length
Uint8Array, Uint16Array, Uint32Array?
Please :
> Yes, they do, via Web Workers.
Which are not part of the javascript spec, it is DOM related. And web workers were never meant to increase performance. In fact in practice they don't, they often make code slower. They just guarantee that the UI thread will not block.
> new Array(10)?
Which doesn't allow any specific runtime optimization as the array can be resized at anytime
> Uint8Array, Uint16Array, Uint32Array?
Which doesn't give me an integer of a specific size BUT any array of integer.
> Yes, they do, via Web Workers.
Which are not part of the javascript spec, it is DOM related. And web workers were never meant to increase performance. In fact in practice they don't, they often make code slower. They just guarantee that the UI thread will not block.
> new Array(10)?
Which doesn't allow any specific runtime optimization as the array can be resized at anytime
> Uint8Array, Uint16Array, Uint32Array?
Which doesn't give me an integer of a specific size BUT any array of integer.
Most performance problems with websites/webapps out there are just due to sheer nastiness of the shovelware that they embed. No need to have fine-tuned debugging and profiling when the main fix is "don't accidentally run this jQuery selector 1000 times on every click". Very low hanging fruit.
> the memory is impossible to manage.
Nonsense. There are plenty of strategies for managing memory efficiently in JavaScript. Yes you can't do a C++ level of allocation, decallocation, etc but you most certainly can manage the amount of memory your code uses.
Nonsense. There are plenty of strategies for managing memory efficiently in JavaScript. Yes you can't do a C++ level of allocation, decallocation, etc but you most certainly can manage the amount of memory your code uses.
This is a non-argument. Firstly, JS does indeed have typed arrays and other tools for managing memory. More importantly, unless you're doing 3D or similar it's vanishingly rare that the memory used by objects you've allocated in JS will be measurable compared to the memory used for DOM objects and rendering generally. Replacing JS with some other language wouldn't affect the memory usage of typical web pages.
I think the spirit of the argument is that if you have requirements for heavy computation such that you need multithreading + low level memory management, then you probably shouldn't use this. Use the right tool for the job. This is just one of them.
Plus there are alternatives to threads. Look at the state of Atom or VSCode. Much progress has been made in terms of perf and these are not trivial applications.
Plus there are alternatives to threads. Look at the state of Atom or VSCode. Much progress has been made in terms of perf and these are not trivial applications.
> Use the right tool for the job
That's a funny argument in a thread about js. Js has started as a small language to do scripting on the pages, now they are sticking it everywhere.
That's a funny argument in a thread about js. Js has started as a small language to do scripting on the pages, now they are sticking it everywhere.
Because people don't actually use the right tool for the job when it comes to software. Instead, they take the tool they know, ignore the better tools they would rather not have to learn, and make the known tool do things it was never designed for.
Excel is a great example of that, but it's done with programming languages as well.
Excel is a great example of that, but it's done with programming languages as well.
Slightly nitpicky, but while lack of support for multithreading might make a particular app slow or unresponsive, I'd have thought it makes it less likely for that app to be able to bring the entire system to its knees.
No disagreement about memory usage, except to say that [some web sites] are usually either poorly or unethically coded. I was on theverge.com yesterday, wondering why the network indicator was going crazy on a blog post. Pull up dev tools and it's ad code downloading megs worth of data, endlessly. Whether that's on theverge, or bad actor for ad code; I don't know or care - but when people talk about bad websites that's usually the primary example in my experience.
See the spotify client, popcorn time, visual studio code. these are javascript. They run great.
Have you checked how much memory they use?
I know we have 8-core laptops with 16 gigs of RAM, but, still, it's excessive.
I know we have 8-core laptops with 16 gigs of RAM, but, still, it's excessive.
Don't have an 8 core, or 16 gigs of ram. I'm talking about my desktop. I have a 4 core i5 from 2013. Spotify has 173M in res. Visual studio code with 10 files open has 99M in res. I have firefox open with about 125 tabs open, 6 terminal windows, 2 pdf files open, VLC open but not playing, IRC in about 15 channels. Load average is 0.60. Memory load across all CPU's about 10%. 8gigs used out of 12gigs of ram. With firefox using 5.1 gigs.
Also the Slack web client
It is pretty excessive, but maybe web assembly would find a real home in making applications that do well on both native and web.
WebAssembly will hopefully end JavaScript's stranglehold on the web.
The justification for using JavaScript for server/desktop/mobile applications seems to essentially be that a certain large group of programmers only know JavaScript.
The justification for using JavaScript for server/desktop/mobile applications seems to essentially be that a certain large group of programmers only know JavaScript.
I'm not sure. All the browser APIs will still use the JS object model. If we look at the situation on the JVM or CLR, it seems like languages specifically designed for those object models (even if adapted from other languages) have been more successful than attempts to directly port existing languages. e.g., Scala, Clojure, F# or Powershell vs. Jython, JRuby, C++/CLI or IronPython.
My bet would be that languages specifically designed for the JS ecosystem (whether JS itself or something like CoffeeScript or TypeScript) will continue to be the most popular for writing most of an app, with some apps dropping down to C or C++ or Rust compiled to wasm for a subset of performance-critical code.
My bet would be that languages specifically designed for the JS ecosystem (whether JS itself or something like CoffeeScript or TypeScript) will continue to be the most popular for writing most of an app, with some apps dropping down to C or C++ or Rust compiled to wasm for a subset of performance-critical code.
I'm sure there'll be a mix. But consider things like Opal (Ruby => javascript), and it seems like there's at least some people who very much want to be able to work in a single language, but for that language to not be javascript...
I'm sure once webassembly is ready, that'll at least get more popular.
I'm sure once webassembly is ready, that'll at least get more popular.
I guess you tend to reuse the technologies you're familiar with, especially when they are very well proven for solving a very complicated problem that requires a lot of expertise (I'm talking about fancy UIs, of course).
Which is also why I think the emphasis on JS is wrong: the main selling point of these technologies is NOT javascript, is HTML5/ CSS. Javascript is just a (very handy indeed) scripting language like any other: frankly the logic and requirements of most applications around are not complex enough to justify the usage of anything more solid or complicated than that. Just today I was contacted by a former colleague, a Java developer, asking advice on using Electron to develop a quick desktop application.
On the other hand, there is a long list of languages that transpile to javascript. So where are the masses of serious C#/ Java/ <pick-your-language> developers using transpilers to write the logic of their web applications?
Which is also why I think the emphasis on JS is wrong: the main selling point of these technologies is NOT javascript, is HTML5/ CSS. Javascript is just a (very handy indeed) scripting language like any other: frankly the logic and requirements of most applications around are not complex enough to justify the usage of anything more solid or complicated than that. Just today I was contacted by a former colleague, a Java developer, asking advice on using Electron to develop a quick desktop application.
On the other hand, there is a long list of languages that transpile to javascript. So where are the masses of serious C#/ Java/ <pick-your-language> developers using transpilers to write the logic of their web applications?
So where are the masses of serious C#/ Java/ <pick-your-language> developers using transpilers to write the logic of their web applications?
I think it is catching on with C++ game developers, who want to be able to run the same codebase natively or in the web browser. The Unity 3D game engine has built-in support for this using WebGL, for example.
I don't know if CLR or JVM languages have been successfully transpiled to the browser using asm.js / WebAssembly (it wouldn't be very efficient at all, so I doubt that will ever be popular).
I think it is catching on with C++ game developers, who want to be able to run the same codebase natively or in the web browser. The Unity 3D game engine has built-in support for this using WebGL, for example.
I don't know if CLR or JVM languages have been successfully transpiled to the browser using asm.js / WebAssembly (it wouldn't be very efficient at all, so I doubt that will ever be popular).
Agreed, Im so tired of being forced to write js.
Too much wishful thinking during the second half of the talk, though.
Also, while fancy runtime systems can improve the performance of dynamic[0] languages, it doesn't come for free: the price to be paid is the loss of elegance. For instance, a JIT compiler could inline a virtual method that seems not to be overridden anywhere, but if later on it turns out that the virtual method was overridden somewhere, the “optimization” has to be undone. How can anyone in their right mind trust a language that requires such dirty implementation tricks to achieve decent performance?
[0] By which I mean “less amenable to static analysis”, regardless of whether the language has a static type system. For instance, Java and C# are dynamic languages in this sense.
Also, while fancy runtime systems can improve the performance of dynamic[0] languages, it doesn't come for free: the price to be paid is the loss of elegance. For instance, a JIT compiler could inline a virtual method that seems not to be overridden anywhere, but if later on it turns out that the virtual method was overridden somewhere, the “optimization” has to be undone. How can anyone in their right mind trust a language that requires such dirty implementation tricks to achieve decent performance?
[0] By which I mean “less amenable to static analysis”, regardless of whether the language has a static type system. For instance, Java and C# are dynamic languages in this sense.
trust a language that ...
JIT compilers work. Most high-level languages require compiler tricks for achieving performance from Scala to Haskell to Prolog.
It's useful to distinguish between (1) having a clean, easy to understand semantics and (2) having a fast implementation. Use all the hackery in the world to get your language fast, as long as it's abstract semantics is easy and canonical.
> Most high-level languages require compiler tricks for achieving performance from Scala to Haskell to Prolog.
To make things perfectly clear: I'm not against optimizations being performed automatically by compilers or runtime systems. What I'm against is unclean designs: deliberately performing an unsound optimization and then rolling it back is an unclean design.
> Use all the hackery in the world to get your language fast,
The language implementation is a program itself, and I don't have any good reasons to trust a hackish language implementation any more than I trust other hackish programs - that is, not at all.
> as long as it's abstract semantics is easy and canonical.
Hah! This thread is about JavaScript.
To make things perfectly clear: I'm not against optimizations being performed automatically by compilers or runtime systems. What I'm against is unclean designs: deliberately performing an unsound optimization and then rolling it back is an unclean design.
> Use all the hackery in the world to get your language fast,
The language implementation is a program itself, and I don't have any good reasons to trust a hackish language implementation any more than I trust other hackish programs - that is, not at all.
> as long as it's abstract semantics is easy and canonical.
Hah! This thread is about JavaScript.
is an unclean design.
trust a hackish language implementation
> It's not unsound. Otherwise you'd incorrect results. You could say it's wasteful, because you optimise and then throw away the optimisation.
The optimization is unsound. If it weren't, it wouldn't have to be rolled back occasionally.
If you're talking about the combination of the optimization and the rollback mechanism, it's not unsound, but it's inelegant. A runtime system designed this way only understands your program in a statistical sense (based on concrete execution profiles, which may vary from one run to another), never with the full certainty that static analyses (type checking, abstract interpretation) can give you.
> how many of the bugs in your code turned out to be compiler bugs, vs how many were ultimately your mistakes?
Of course, most were my mistakes. But the very reason why those bugs made it into the final executable is the lack of powerful static analyses in the first place. Curiously enough, when I use languages that make static analyses possible, I write programs with less bugs and they perform better without relying on fancy runtime system tricks.
---
Sorry, can't reply to you guys, because “I'm submitting too fast”. So my replies go here:
@mafribe:
> That's an orthogonal issue.
It's not. Static analyses gather valuable information that can be used to emit efficient code.
> More powerful static analysis is also more time-consuming.
So perform it ahead of time!
> One of the design goals of Javascript JITs is to make web-pages as responsive as possible. That rules out complicated static analysis.
Of course, a browser can't spend much time statically analyzing JavaScript programs, but programs can be statically analyzed (gasp!) before they're deployed.
---
@smallnamespace:
> Why does that matter to anyone?
Because this implementation technique is unnecessarily complex, and a far simpler alternative exists: Know beforehand what your program has to do. Think before you write code.
> Java and C# are both statically, strongly typed languages where JITs are the dominant implementation.
Their type systems can be easily subverted, so they're not “strongly typed” in my book.
---
@smallnamespace: Oops, sorry, I accidentally swapped my two replies to you: this one and https://news.ycombinator.com/item?id=12481956 .
The optimization is unsound. If it weren't, it wouldn't have to be rolled back occasionally.
If you're talking about the combination of the optimization and the rollback mechanism, it's not unsound, but it's inelegant. A runtime system designed this way only understands your program in a statistical sense (based on concrete execution profiles, which may vary from one run to another), never with the full certainty that static analyses (type checking, abstract interpretation) can give you.
> how many of the bugs in your code turned out to be compiler bugs, vs how many were ultimately your mistakes?
Of course, most were my mistakes. But the very reason why those bugs made it into the final executable is the lack of powerful static analyses in the first place. Curiously enough, when I use languages that make static analyses possible, I write programs with less bugs and they perform better without relying on fancy runtime system tricks.
---
Sorry, can't reply to you guys, because “I'm submitting too fast”. So my replies go here:
@mafribe:
> That's an orthogonal issue.
It's not. Static analyses gather valuable information that can be used to emit efficient code.
> More powerful static analysis is also more time-consuming.
So perform it ahead of time!
> One of the design goals of Javascript JITs is to make web-pages as responsive as possible. That rules out complicated static analysis.
Of course, a browser can't spend much time statically analyzing JavaScript programs, but programs can be statically analyzed (gasp!) before they're deployed.
---
@smallnamespace:
> Why does that matter to anyone?
Because this implementation technique is unnecessarily complex, and a far simpler alternative exists: Know beforehand what your program has to do. Think before you write code.
> Java and C# are both statically, strongly typed languages where JITs are the dominant implementation.
Their type systems can be easily subverted, so they're not “strongly typed” in my book.
---
@smallnamespace: Oops, sorry, I accidentally swapped my two replies to you: this one and https://news.ycombinator.com/item?id=12481956 .
> it's not unsound, but it's inelegant. A runtime system designed this way only understands your program in a statistical sense (based on concrete execution profiles, which may vary from one run to another), never with the full certainty that static analyses (type checking, abstract interpretation) can give you.
This is a false dichotomy. You can always build a JIT that uses runtime statistics to speed things up, even in languages that are quite amenable to static analysis, for the simple reason that type systems cannot capture all relevant runtime context. Java is a good example here, since it's strongly statically typed.
By your reckoning, all optimistic heuristics that CPUs do like branch prediction and prefetching are also similarly 'inelegant', because they can be wrong and require rolling back.
Optimistic heuristics have a long history in computer science, and IMO it seems strange to single one particular use case as being particularly evil.
This is a false dichotomy. You can always build a JIT that uses runtime statistics to speed things up, even in languages that are quite amenable to static analysis, for the simple reason that type systems cannot capture all relevant runtime context. Java is a good example here, since it's strongly statically typed.
By your reckoning, all optimistic heuristics that CPUs do like branch prediction and prefetching are also similarly 'inelegant', because they can be wrong and require rolling back.
Optimistic heuristics have a long history in computer science, and IMO it seems strange to single one particular use case as being particularly evil.
The optimization is unsound.
but it's inelegant.
lack of powerful static analyses
> How can anyone in their right mind trust a language that requires such dirty implementation tricks to achieve decent performance?
Isn't this a rather broad brush with which to paint all JIT language implementations, including Java, C#, and, say, PyPy?
Isn't this a rather broad brush with which to paint all JIT language implementations, including Java, C#, and, say, PyPy?
Could you name a JIT compiler that doesn't do this kind of thing, yet offers performance comparable to AOT-compiled languages?
(FWIW, I'm not saying it's impossible. It's perfectly possible, but you'd need a source language that offers much better static guarantees than the typical language that a JIT compiler is written for.)
---
Sorry, can't reply to you directly, because “I'm submitting too fast”. So my reply goes here:
> for the simple reason that type systems cannot capture all relevant runtime context.
Type checking isn't the only kind of static analysis out there. And there's no need to use statistics to optimize anything at runtime when your ahead-of-time compilation step already emits optimal target machine code.
> Java is a good example here, since it's strongly statically typed.
Java is as dynamically typed as it gets: `instanceof`, downcasts and reflection, all conspire to reduce the usefulness of static type information to zero.
> By your reckoning, all greedy optimizations that CPUs do like branch prediction and prefetching are also similarly 'inelegant', because they can be wrong and require rolling back.
Yes, indeed. It's more elegant to know beforehand what exactly you have to do, and then do just that and nothing else.
(FWIW, I'm not saying it's impossible. It's perfectly possible, but you'd need a source language that offers much better static guarantees than the typical language that a JIT compiler is written for.)
---
Sorry, can't reply to you directly, because “I'm submitting too fast”. So my reply goes here:
> for the simple reason that type systems cannot capture all relevant runtime context.
Type checking isn't the only kind of static analysis out there. And there's no need to use statistics to optimize anything at runtime when your ahead-of-time compilation step already emits optimal target machine code.
> Java is a good example here, since it's strongly statically typed.
Java is as dynamically typed as it gets: `instanceof`, downcasts and reflection, all conspire to reduce the usefulness of static type information to zero.
> By your reckoning, all greedy optimizations that CPUs do like branch prediction and prefetching are also similarly 'inelegant', because they can be wrong and require rolling back.
Yes, indeed. It's more elegant to know beforehand what exactly you have to do, and then do just that and nothing else.
> that _doesn't_ do this kind of thing
Why does that matter to anyone?
> you'd need a source language that offers much better static guarantees than the typical language that a JIT compiler is written for
Java and C# are both statically, strongly typed languages where JITs are the dominant implementation.
Almost by definition, it's impossible to write a JIT compiler that outperforms AOT compilation without looking at runtime data, because AOT compilers have a lot more time to look for difficult static optimizations. The reason JITs can keep up is because they have access to information that an AOT compiler does not.
> And there's no need to use statistics to optimize anything at runtime when your ahead-of-time compilation step already emits optimal target machine code.
This is simply untrue. For example, it's not possible to statically determine whether a function should be inlined or not. However, a JIT can see that it's used in a hot loop and dynamically inline.
For any language, no matter the type system, runtime information will always be a superset of compile-time information. There will always exist optimizations in a JIT that aren't possible in an AOT compiler.
> Java is as dynamically typed as it gets: `instanceof`, downcasts and reflection, all conspire to reduce the usefulness of static type information to zero.
Idiomatic Java code doesn't use these features heavily. Just because it's possible to wipe out type information doesn't mean that the vast majority of code that an AOT or JIT compiler sees won't be strongly typed.
Why does that matter to anyone?
> you'd need a source language that offers much better static guarantees than the typical language that a JIT compiler is written for
Java and C# are both statically, strongly typed languages where JITs are the dominant implementation.
Almost by definition, it's impossible to write a JIT compiler that outperforms AOT compilation without looking at runtime data, because AOT compilers have a lot more time to look for difficult static optimizations. The reason JITs can keep up is because they have access to information that an AOT compiler does not.
> And there's no need to use statistics to optimize anything at runtime when your ahead-of-time compilation step already emits optimal target machine code.
This is simply untrue. For example, it's not possible to statically determine whether a function should be inlined or not. However, a JIT can see that it's used in a hot loop and dynamically inline.
For any language, no matter the type system, runtime information will always be a superset of compile-time information. There will always exist optimizations in a JIT that aren't possible in an AOT compiler.
> Java is as dynamically typed as it gets: `instanceof`, downcasts and reflection, all conspire to reduce the usefulness of static type information to zero.
Idiomatic Java code doesn't use these features heavily. Just because it's possible to wipe out type information doesn't mean that the vast majority of code that an AOT or JIT compiler sees won't be strongly typed.
> For example, it's not possible to statically determine whether a function should be inlined or not.
MLton has absolutely no problems inlining functions, even higher-order functions, at compile time. This is only difficult in languages with virtual methods, because they can be overridden anywhere. If anything, that's an indictment of virtual methods, not AOT compilers.
> However, a JIT can see that it's used in a hot loop and dynamically inline.
What if it's a virtual method call that's known to be overridden in several places? You can't inline it, even if it's in the middle of a hot loop.
> For any language, no matter the type system, runtime information will always be a superset of compile-time information.
Runtime information is always anecdotal, specific to one particular run of a program, so...
> There will always exist optimizations in a JIT that aren't possible in an AOT compiler.
... for every “optimization” a JIT can perform, there will always exist a program for which the “optimization” will have to be rolled back after it has already been performed, because it turned out to be unsound.
> Idiomatic Java code doesn't use these features heavily.
Language implementations must work correctly whether you write idiomatic or unidiomatic code.
> Just because it's possible to wipe out type information doesn't mean that the vast majority of code that an AOT or JIT compiler sees won't be strongly typed.
Most code I write in Python could be given static types too. That doesn't make Python a statically typed language.
And “strongly typed” doesn't really mean anything.
MLton has absolutely no problems inlining functions, even higher-order functions, at compile time. This is only difficult in languages with virtual methods, because they can be overridden anywhere. If anything, that's an indictment of virtual methods, not AOT compilers.
> However, a JIT can see that it's used in a hot loop and dynamically inline.
What if it's a virtual method call that's known to be overridden in several places? You can't inline it, even if it's in the middle of a hot loop.
> For any language, no matter the type system, runtime information will always be a superset of compile-time information.
Runtime information is always anecdotal, specific to one particular run of a program, so...
> There will always exist optimizations in a JIT that aren't possible in an AOT compiler.
... for every “optimization” a JIT can perform, there will always exist a program for which the “optimization” will have to be rolled back after it has already been performed, because it turned out to be unsound.
> Idiomatic Java code doesn't use these features heavily.
Language implementations must work correctly whether you write idiomatic or unidiomatic code.
> Just because it's possible to wipe out type information doesn't mean that the vast majority of code that an AOT or JIT compiler sees won't be strongly typed.
Most code I write in Python could be given static types too. That doesn't make Python a statically typed language.
And “strongly typed” doesn't really mean anything.
> MLton has absolutely no problems inlining functions, even higher-order functions, at compile time
Of course, but how does it know which functions to inline? If you inline everything, then you will blow through your cache.
> What if it's a virtual method call that's known to be overridden in several places? You can't inline it, even if it's in the middle of a hot loop.
That's not true--a JIT could optimistically replace with a concrete realization.
> Runtime information is always anecdotal, specific to one particular run of a program, so...
That's a benefit. No matter what AOT compiled code you have, it is possible to speed up execution if you know what code paths you will take.
> ... for every “optimization” a JIT can perform, there will always exist a program for which the “optimization” will have to be rolled back after it has already been performed, because it turned out to be unsound.
Yes, but so what? As long as it improves performance in the average case, and the worst case is bounded, then that is a net win. You can equally well write deliberately obfuscated code that an AOT compiler has trouble with.
> Language implementations must work correctly whether you write idiomatic or unidiomatic code.
Implementation is correct. Only reflection is slow. If you don't want that, don't write reflection.
Of course, but how does it know which functions to inline? If you inline everything, then you will blow through your cache.
> What if it's a virtual method call that's known to be overridden in several places? You can't inline it, even if it's in the middle of a hot loop.
That's not true--a JIT could optimistically replace with a concrete realization.
> Runtime information is always anecdotal, specific to one particular run of a program, so...
That's a benefit. No matter what AOT compiled code you have, it is possible to speed up execution if you know what code paths you will take.
> ... for every “optimization” a JIT can perform, there will always exist a program for which the “optimization” will have to be rolled back after it has already been performed, because it turned out to be unsound.
Yes, but so what? As long as it improves performance in the average case, and the worst case is bounded, then that is a net win. You can equally well write deliberately obfuscated code that an AOT compiler has trouble with.
> Language implementations must work correctly whether you write idiomatic or unidiomatic code.
Implementation is correct. Only reflection is slow. If you don't want that, don't write reflection.
> Of course, but how does it know which functions to inline?
Small functions and higher-order functions are the most natural candidates. (The two categories greatly overlap in most cases.)
> That's not true--a JIT could optimistically replace with a concrete realization.
You'd have to roll back an unsound optimization in the middle of a hot loop. I'm pretty sure that's not what you want.
> it is possible to speed up execution if you know what code paths you will take.
That knowledge can be encoded statically in many cases, if only you used the right languages.
> As long as it improves performance in the average case, and the worst case is bounded, then that is a net win.
This is only the case when your program wasn't close to optimal to begin with.
> You can equally well write deliberately obfuscated code that an AOT compiler has trouble with.
Yes, but languages amenable to static analysis will actively get in your way if you try to write such obfuscated code. The static analysis either tells you that your program is gibberish, or outputs nonsensical gibberish of its own. So the path of least resistance is to write code that the static analysis knows how to optimize. Which is not the case in dynamic languages (including pseudo-static ones like Java).
> Only reflection is slow. If you don't want that, don't write reflection.
So. basically, you're telling me to ditch Java's entire library and framework ecosystem?
Small functions and higher-order functions are the most natural candidates. (The two categories greatly overlap in most cases.)
> That's not true--a JIT could optimistically replace with a concrete realization.
You'd have to roll back an unsound optimization in the middle of a hot loop. I'm pretty sure that's not what you want.
> it is possible to speed up execution if you know what code paths you will take.
That knowledge can be encoded statically in many cases, if only you used the right languages.
> As long as it improves performance in the average case, and the worst case is bounded, then that is a net win.
This is only the case when your program wasn't close to optimal to begin with.
> You can equally well write deliberately obfuscated code that an AOT compiler has trouble with.
Yes, but languages amenable to static analysis will actively get in your way if you try to write such obfuscated code. The static analysis either tells you that your program is gibberish, or outputs nonsensical gibberish of its own. So the path of least resistance is to write code that the static analysis knows how to optimize. Which is not the case in dynamic languages (including pseudo-static ones like Java).
> Only reflection is slow. If you don't want that, don't write reflection.
So. basically, you're telling me to ditch Java's entire library and framework ecosystem?
> Small functions and higher-order functions are the most natural candidates. (The two categories greatly overlap in most cases.)
But then you're just guessing. Isn't that also inelegant?
Let's play devil's advocate: how do you decide the cutoff on function size for inlining? Well, you would profile a bunch of programs with various cutoffs... now all you have is a heuristic, and MLton will inline some functions that it shouldn't, and it will fail to inline other functions that it should.
It will do worse than a JIT at this, because the JIT has more information.
> That knowledge can be encoded statically in many cases, if only you used the right languages.
Sure, but you won't ever succeed in encoding all of it, which is why runtime techniques can have a place.
> This is only the case when your program wasn't close to optimal to begin with.
That's simply untrue, and you can prove that formally -- given a machine M and a program P that produces outputs on a set of inputs I, it is always possible to come up with a program P' that produces those outputs with fewer steps on some subset of I, in return for taking more steps on the rest of I (except in the trivial case where the running time is completely independent of input).
You can view a JIT as iteratively replacing P with P' after it sees which inputs I are most common, and this is true no matter what M, P, or I are. In particular, there exists a version of P' that is faster than the statically optimized version of P on your program's input.
> Yes, but languages amenable to static analysis will actively get in your way if you try to write such obfuscated code.
I don't see how that isn't equally applicable to writing code to fool your JIT.
> So. basically, you're telling me to ditch Java's entire library and framework ecosystem?
Framework code doesn't generally run inside your inner loops, so I don't see how that should affect either your AOT or JIT compiler much.
But then you're just guessing. Isn't that also inelegant?
Let's play devil's advocate: how do you decide the cutoff on function size for inlining? Well, you would profile a bunch of programs with various cutoffs... now all you have is a heuristic, and MLton will inline some functions that it shouldn't, and it will fail to inline other functions that it should.
It will do worse than a JIT at this, because the JIT has more information.
> That knowledge can be encoded statically in many cases, if only you used the right languages.
Sure, but you won't ever succeed in encoding all of it, which is why runtime techniques can have a place.
> This is only the case when your program wasn't close to optimal to begin with.
That's simply untrue, and you can prove that formally -- given a machine M and a program P that produces outputs on a set of inputs I, it is always possible to come up with a program P' that produces those outputs with fewer steps on some subset of I, in return for taking more steps on the rest of I (except in the trivial case where the running time is completely independent of input).
You can view a JIT as iteratively replacing P with P' after it sees which inputs I are most common, and this is true no matter what M, P, or I are. In particular, there exists a version of P' that is faster than the statically optimized version of P on your program's input.
> Yes, but languages amenable to static analysis will actively get in your way if you try to write such obfuscated code.
I don't see how that isn't equally applicable to writing code to fool your JIT.
> So. basically, you're telling me to ditch Java's entire library and framework ecosystem?
Framework code doesn't generally run inside your inner loops, so I don't see how that should affect either your AOT or JIT compiler much.
>Let's play devil's advocate: how do you decide the cutoff on function size for inlining
AOT compiler writers have been tuning inline heuristics for more than 40 years. Sure sometimes you have to help the compiler with annotations or PGO, but in the large majority of cases things just work.
In fact AOT can deal much better with the massive code explosion due to aggressive inlining than JIT compilers which have a very tight time budget for optimisations.
AOT compiler writers have been tuning inline heuristics for more than 40 years. Sure sometimes you have to help the compiler with annotations or PGO, but in the large majority of cases things just work.
In fact AOT can deal much better with the massive code explosion due to aggressive inlining than JIT compilers which have a very tight time budget for optimisations.
> In particular, there exists a version of P' that is faster than the statically optimized version of P on your program's input.
Sure, but I'm interested in what the program does on all meaningful inputs, not a specific one. Otherwise, I'd just precompute the answer and hardcode it.
> I don't see how that isn't equally applicable to writing code to fool your JIT.
AOT compilers are supposed to provide feedback to the programmer about what the program means (e.g., inferred types, type errors). JIT compilers are not.
> I don't really understand why optimistic heuristics bother you so much.
Um, because they can be wrong, and then you need to fix errors, which makes the system more complex?
> Seems like you just have an aesthetic preference.
Yes, for simplicity, and for thinking before writing code.
Sure, but I'm interested in what the program does on all meaningful inputs, not a specific one. Otherwise, I'd just precompute the answer and hardcode it.
> I don't see how that isn't equally applicable to writing code to fool your JIT.
AOT compilers are supposed to provide feedback to the programmer about what the program means (e.g., inferred types, type errors). JIT compilers are not.
> I don't really understand why optimistic heuristics bother you so much.
Um, because they can be wrong, and then you need to fix errors, which makes the system more complex?
> Seems like you just have an aesthetic preference.
Yes, for simplicity, and for thinking before writing code.
> Um, because they can be wrong, and then you need to fix errors, which makes the system more complex?
Yes, but I don't understand why compiler complexity concerns you, so long as the whole thing works. AOT compilers are also extremely complex, and are also full of heuristics.
You seem really hung up on the fact that an optimization can be rolled back at some point, but why should you care? JIT optimizations can be 'wrong' in the same way that caches can miss. It the right engineering solution to eliminate caching, over some belief that one should never be 'wrong' anywhere in a program, even though the eventual answer is always correct?
This might matter in system with real-time performance demands, but then you should be equally concerned about the garbage collector, for example.
Yes, but I don't understand why compiler complexity concerns you, so long as the whole thing works. AOT compilers are also extremely complex, and are also full of heuristics.
You seem really hung up on the fact that an optimization can be rolled back at some point, but why should you care? JIT optimizations can be 'wrong' in the same way that caches can miss. It the right engineering solution to eliminate caching, over some belief that one should never be 'wrong' anywhere in a program, even though the eventual answer is always correct?
This might matter in system with real-time performance demands, but then you should be equally concerned about the garbage collector, for example.
> Yes, but I don't understand why you compiler complexity concerns you, so long as the whole thing works.
Because I find it easier to trust simpler systems than complex ones.
> AOT compilers are also extremely complex, and are also full of heuristics.
Yep, those heuristics are annoying too. (But less so than the ones JIT compilers use, because at least they don't involve temporarily breaking my program.)
> unless you've profiled it and see this having a real adverse effect on overall performance?
How many times do I have to repeat that what annoys me is the excessive complexity?
Because I find it easier to trust simpler systems than complex ones.
> AOT compilers are also extremely complex, and are also full of heuristics.
Yep, those heuristics are annoying too. (But less so than the ones JIT compilers use, because at least they don't involve temporarily breaking my program.)
> unless you've profiled it and see this having a real adverse effect on overall performance?
How many times do I have to repeat that what annoys me is the excessive complexity?
it's interesting that C# has recently moved away from JIT and reflection for client apps (.NET Native), though.
Linux is more successful on the desktop than it's ever been, and Gnome is largely powered by JavaScript. The Gnome extensions repository is a huge JavaScript success. Never before has WM customization been so accessible.
The Universal Windows Platform also has a JavaScript API that is a breeze compared to the old Win32 development process.
Electron is good but just the tip of the iceberg. I think it says more that major OSes have bet their future on JavaScript.
The Universal Windows Platform also has a JavaScript API that is a breeze compared to the old Win32 development process.
Electron is good but just the tip of the iceberg. I think it says more that major OSes have bet their future on JavaScript.
Anecdote time: after I did a distupgrade of my kubuntu desktop to the next kubuntu release, kwin kept crashing for some reason, probably due to a botched package update. After attaching gdb to the dying process I found out that it was dying inside a javascript interpreter.
Not wanting to know WTF a JS interpreter was doing inside the window manager, I wiped kubuntu, installed plain debian and now I'm happily running xfce on my desktop too.
Of course now someone will tell me that xfce has also been similarly infected...
Not wanting to know WTF a JS interpreter was doing inside the window manager, I wiped kubuntu, installed plain debian and now I'm happily running xfce on my desktop too.
Of course now someone will tell me that xfce has also been similarly infected...
> Linux is more successful on the desktop than it's ever been, and Gnome is largely powered by JavaScript.
You mean gjs which is a poor javascript runtime. And Gnome is largely powered by C more than javascript. You may use javascript because Gobject-introspection which is also available for perl and python.
You mean gjs which is a poor javascript runtime. And Gnome is largely powered by C more than javascript. You may use javascript because Gobject-introspection which is also available for perl and python.
More likely they see a lot of programmers who only know JavaScript and they want to offer them something.
Is that a bad thing?
No, well programmers just knowing JavaScript is but catering to a wider audience is a good thing.
was just about to say: it's not damn javascript, it's the damn developers.
it's really becoming like java. pushed every, but the wrong choice on many occasions.
it's really becoming like java. pushed every, but the wrong choice on many occasions.
> Linux is more successful on the desktop than it's ever been
That's not saying much since Linux is pretty much nonexistent on the desktop.
That's not saying much since Linux is pretty much nonexistent on the desktop.
No, gnome is "largely" powered by C, like the vast majority of other performant software out there.
My biggest issue with these apps is the inability to share memory. If I have Viber, Slack, Atom and regular Chromium open at the same time, they all consume copious amounts of memory which I assume is due to the constant overhead layout/JS engines need to keep resident per app.
If I'd somehow opened all these as tabs on Chromium, they would plug into Chromium's already-allocated shared data structures and the memory consumed would be quite lower. I can have Facebook Messenger, Deezer and Gmail open alongside 10+ other tabs at all times, but once I start Slack and Viber alongside Chromium (or Skype for Linux Alpha, or Visual Studio Code, or Black Screen, or any of these trendy hybrid-web-desktop apps), Linux starts screaming and swapping things around; as a result, everything becomes sluggish.
Also, the apps themselves feel a bit laggy even when they have all the memory they need. I know the comparison is not fair, but using, say, Code::Blocks or QtCreator (which are full-blown IDEs) with Atom, I can feel input response differences for some reason.
I have a low amount of RAM on my home PC and I plan on upgrading it, so you can say that my hardware is the problem, but clogging up memory like that is always a waste.
As a test, I just opened Popcorn Time. Right after startup, it uses 200MB of resident memory. The whole GNOME shell + the Xorg process consume around 280MB combined on my PC. That's insane. Yes, it looks beautiful, but it's nothing you can't do with Qt these days. It also supports JavaScript. QML is not hard to learn. It's available for Windows, Linux, OS X, and even mobile. Ditto for GTK+ 3: Vala is beautiful, practically C#, and good enough for at least the UI layer of your app, if not for the whole thing. Qt and GTK+ are both open source and LGPL, which means you can freely link to them even if you develop proprietary software.
I just don't see such a need to make today's apps so bloated (and I don't consider "people have enough memory nowadays" a valid argument). If it's an one-off app made by a small team, or for fun, the trade-offs may be worth it. But for Slack, or Skype for Linux, or VS Code, wouldn't it make sense to put more developer time on it and have a much more performance-conscious application?
If I'd somehow opened all these as tabs on Chromium, they would plug into Chromium's already-allocated shared data structures and the memory consumed would be quite lower. I can have Facebook Messenger, Deezer and Gmail open alongside 10+ other tabs at all times, but once I start Slack and Viber alongside Chromium (or Skype for Linux Alpha, or Visual Studio Code, or Black Screen, or any of these trendy hybrid-web-desktop apps), Linux starts screaming and swapping things around; as a result, everything becomes sluggish.
Also, the apps themselves feel a bit laggy even when they have all the memory they need. I know the comparison is not fair, but using, say, Code::Blocks or QtCreator (which are full-blown IDEs) with Atom, I can feel input response differences for some reason.
I have a low amount of RAM on my home PC and I plan on upgrading it, so you can say that my hardware is the problem, but clogging up memory like that is always a waste.
As a test, I just opened Popcorn Time. Right after startup, it uses 200MB of resident memory. The whole GNOME shell + the Xorg process consume around 280MB combined on my PC. That's insane. Yes, it looks beautiful, but it's nothing you can't do with Qt these days. It also supports JavaScript. QML is not hard to learn. It's available for Windows, Linux, OS X, and even mobile. Ditto for GTK+ 3: Vala is beautiful, practically C#, and good enough for at least the UI layer of your app, if not for the whole thing. Qt and GTK+ are both open source and LGPL, which means you can freely link to them even if you develop proprietary software.
I just don't see such a need to make today's apps so bloated (and I don't consider "people have enough memory nowadays" a valid argument). If it's an one-off app made by a small team, or for fun, the trade-offs may be worth it. But for Slack, or Skype for Linux, or VS Code, wouldn't it make sense to put more developer time on it and have a much more performance-conscious application?
When I choose softwares, I tend to choose native one over electron or JavaFX ones. It feels more native and more "sincere", like the developer really want to make it a good software. I know this logic doesn't make sense, but I don't mind paying more if it is native. It's like a handwritten letter, not a printed one.
> "...I don't mind paying more if it is native..."
I'm curious on how you know this before you even purchase? For example, the Mac app store can have both native and electron apps? You wouldn't know it's native or not until after you purchase it?
I'm curious on how you know this before you even purchase? For example, the Mac app store can have both native and electron apps? You wouldn't know it's native or not until after you purchase it?
1. File size is a big hint.
2. Most of the electron apps doesn't replicate native elements completely, so you can guess it from tiny details like shape and shadow of text field.
3. It is also very common for their windows counterpart to look exactly the same.
[deleted]
Ahem. Let me be the first to say, YUCK!!!
I don't understand why people like this language. I am sure it has it's uses etc., but come on, if you want to build a reliable, easy-to-reason program, using JS is just running up a escalator that is going down.
https://abdulapopoola.com/2015/09/30/why-javascript-seems-to...
http://rhodesmill.org/brandon/2012/js/
http://dorey.github.io/JavaScript-Equality-Table/
https://www.destroyallsoftware.com/talks/wat
http://blog.chewxy.com/2014/01/27/javascript-wat-again/
I can see using js as a target language with a 'transpiler', but JS is just a shitty language to write code.
I don't understand why people like this language. I am sure it has it's uses etc., but come on, if you want to build a reliable, easy-to-reason program, using JS is just running up a escalator that is going down.
https://abdulapopoola.com/2015/09/30/why-javascript-seems-to...
http://rhodesmill.org/brandon/2012/js/
http://dorey.github.io/JavaScript-Equality-Table/
https://www.destroyallsoftware.com/talks/wat
http://blog.chewxy.com/2014/01/27/javascript-wat-again/
I can see using js as a target language with a 'transpiler', but JS is just a shitty language to write code.
"Adobe’s AIR system enabled developers"
it still does, AIR v1.0 was in 2006, we are now at v23.0
Electron is nice but a whole browser engine is a big bloat, you can easily reach 150MB.
Not to go into a debate JS vs AS3, but the AIR runtime have a lot of advantages : AS3 the language is one, the default native API cover a lot of ground, being able to extend those native functionalities with ANE (ActionScript Native Extension) is nice too.
I don't buy the kool-aid that you could use the exact same HTML5/CSS/JS code for both the browser and a desktop app, unless the app is trivial you gonna have to build your UI/UX specifically for the desktop with all the different subtleties between different OS.
So sure you can use something like Electron to easily wrap an already existing web app for the desktop but imho either you are limiting the desktop features you could add or you will soon end up having 2 code base: 1 for the web and 1 for the desktop and that require more resources than just "wrapping it up for the desktop".
it still does, AIR v1.0 was in 2006, we are now at v23.0
Electron is nice but a whole browser engine is a big bloat, you can easily reach 150MB.
Not to go into a debate JS vs AS3, but the AIR runtime have a lot of advantages : AS3 the language is one, the default native API cover a lot of ground, being able to extend those native functionalities with ANE (ActionScript Native Extension) is nice too.
I don't buy the kool-aid that you could use the exact same HTML5/CSS/JS code for both the browser and a desktop app, unless the app is trivial you gonna have to build your UI/UX specifically for the desktop with all the different subtleties between different OS.
So sure you can use something like Electron to easily wrap an already existing web app for the desktop but imho either you are limiting the desktop features you could add or you will soon end up having 2 code base: 1 for the web and 1 for the desktop and that require more resources than just "wrapping it up for the desktop".
More systems like React Native are how JavaScript should be done on the desktop rather than cordova-like things running in a node host. It has approachability but also performance and ubiquity of skill set, very little friction and is better suited for integrating native controls IMO.
React Native is part of a solid continuing trend. I've had a really good experience with the Appcelerator Titanium JS API for Android/iOS, and for the last couple versions iOS has a quality native JS API itself. Now ExponentJS has entered the ring powered by React Native and looks very very promising.
When a business needs to deploy to several platforms at once, it's a quick and success-proven model that still has good performance.
When a business needs to deploy to several platforms at once, it's a quick and success-proven model that still has good performance.
I almost jump to react-native, then I discover that I need to do the npm install bloatware dance.
Is possible to have a more lean setup?
Is possible to have a more lean setup?
because bytecode isn't slow enough
Sure these early days might show this being overkill, or less performant than traditional methods, but my hope is that this newer approach leads to other types of benefical apps. I'm keenly interested in how these types of approaches help for "unhosted" types of apps (see http://unhosted.org/), as well as offline first apps.
No. Javascript frameworks/tools change every few months, by the time you finish a project, everything you used has been superseded by something new. Last year's expert is today's luddite. Change at that pace is unsustainable for long term support of applications.
There are companies using this in production -- saving time and resources! Example: https://mixmax.com/blog/turnkey-electron-apps-with-meteor
I know many languages but JS is what a lot of new companies need, therefore I have devoted myself to it. On my own time, I like to code in C, because it is a pleasure to use something so fast and close to the metal, and requires such a different style of programming (disciplined paranoia) and allows me maximum control over application resources.
IMO C and JS both stink. Give me statically typed, memory managed, expressivity or give me death.
C is a necessary evil (debatably necessary, but at the very least quite useful).
Apart from that, I agree with you. Static typing is a core tool for helping me manage complexity, and I wish I got to use it in my work.
Apart from that, I agree with you. Static typing is a core tool for helping me manage complexity, and I wish I got to use it in my work.
Ya, if JS went away tomorrow and replace by something else I would be happy about it.
Everything evolves, and this is where evolution has led us. Unfortunately.
JS is the cockroach of programming languages
JavaScript didn't "conquer" anything. It was just one of the first languages around when the web was still in its infancy, and simply never went away.
Lets be honest here, Javascript (alternately known as ECMAscript [1]) has done the following: a) progressively adopted new language features like prototypes, closures, generics and the like.
Javascript just being there early wasn't enough. I has improved remarkably over the past 20 years, and the ECMA standards body has been critical to that improvement.
That said, it's still a quirky language and that alone makes a lot of people feel they can't rely on it.
https://en.wikipedia.org/wiki/ECMAScript
Javascript just being there early wasn't enough. I has improved remarkably over the past 20 years, and the ECMA standards body has been critical to that improvement.
That said, it's still a quirky language and that alone makes a lot of people feel they can't rely on it.
https://en.wikipedia.org/wiki/ECMAScript
> Lets be honest here, Javascript (alternately known as ECMAscript [1]) has done the following: a) progressively adopted new language features like prototypes, closures, generics and the like.
JavaScript had prototypes and closures from the beginning, no? Does it really have generics — a quick Googling makes it appear that it's a matter of hand-rolling. But it's been awhile since I've written JavaScript in anger, so perhaps I've missed an announcement since then.
JavaScript had prototypes and closures from the beginning, no? Does it really have generics — a quick Googling makes it appear that it's a matter of hand-rolling. But it's been awhile since I've written JavaScript in anger, so perhaps I've missed an announcement since then.
You're in denial. Javascript is everywhere nowadays. It has become the English of languages. It's not my favorite language but it has improved extensively.
No one wants to maintain a web app, mobile app, and desktop app separately.
No one wants to maintain a web app, mobile app, and desktop app separately.
Sun was making the same sort of promises with Java about write once, run anywhere, because nobody wanted to have to write their application multiple times to target different platforms.
> It has become the English of languages.
I'm pretty sure English is still the English of languages.
JavaScript might be the English of programming languages, though.
I'm pretty sure English is still the English of languages.
JavaScript might be the English of programming languages, though.
You win the pedantic award for today. :)
It doesn't need a lot of thinking that I was referring to programming languages.
Javascript became far more significant than what it used to be. We can largely thank Microsoft (AJAX) and Google (V8) for that.
And Sun, for being assholes about Java.
[deleted]
bologna.
No, I don't think so. Most people do not use JavaScript since it is useful. They use it since it is the only option available on the browser. There is a BIG difference.
> Creating desktop apps in JavaScript lets developers choose from a vast range of freely available code libraries and frameworks, which takes much of the grunt work out of coding
Lots of languages have a wide array of freely available code tooling and frameworks.
Slightly tangentially though, I wonder if we really really put our mind to it, will we be able to just kill JavaScript ?
I mean, I am sure that there are people out there making a living on JavaScript, but please, take one for the team. Learn something else. I hear it is a hot market for developers.
JavaScript is obviously a flawed language[1] that inspires absolutely bad programming that the rest of us has to deal with. The ecosystem is terrible[2] and the community is full of self-righteous assholes[3] who has the collective attention span of a 2 year old [4].
Let's just call this experiment a failure, cut our losses and just.move.on.
[1] https://www.destroyallsoftware.com/talks/wat
[2] http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/
[3] http://atom-morgan.github.io/in-defense-of-douglas-crockford
[4] https://medium.com/@ericclemmons/javascript-fatigue-48d4011b...