Rich client side web apps gone too far (2014)

Re:Rich client side web apps gone too far (2014) by gingerrr on Saturday March 28, 2015 @06:13PM (#9282937)

can we stop conflating the presence of tons of bad practices in the wild with flaws in JS as a language? every language gives you ways to shoot yourself in the foot (c++ anyone?), if you choose to pull the trigger it's not the language's fault. i may not have been writing JS as long as this author (8 years to his 12) but I got over the ambiguity of `this` values 7 years ago. languages exist to provide a specific set of functionality - in this case, dynamic scope resolution - it's frustrating to see bad design choices in app code blamed on the language. vm authors are open with the optimizations they're making, just write your JS to leverage that performance gain

[ Parent | on HN ]

Re:Rich client side web apps gone too far (2014) by mattdeboard on Saturday March 28, 2015 @06:51PM (#9283084)

I mean, his assertions are right. JavaScript is objectively not a well designed language. That said, he still asserts that JavaScript acquired a reputation worse than it deserved not because of its design decisions but because of the platform it was targeting (the browser).

Your comment reads like a reflexive defense of JavaScript since "javascript sucks" wasn't even the point of the essay.

[ Parent | on HN ]

Re:Rich client side web apps gone too far (2014) by dgreensp on Saturday March 28, 2015 @07:20PM (#9283173)

I think you're going to run into trouble with the word "objectively" there.

All languages have warts, and some are much worse than others. I actually think JavaScript's warts are fairly minor compared to C's or Python's, for example, and PHP is in a different league.

In fact, there are almost no other programming languages with JavaScript's basic features: Unicode support out of the box, proper lexical scoping with first-class function closures, high-performance garbage collection, and easy manipulation of strings, arrays, and dictionaries, for example. Python comes pretty close, with slightly wonky scoping and Unicode bolted on, but then JavaScript also has another Python doesn't, which is a spec with multiple first-class implementations, and not to mention a committee that is plotting a great path forwards into the future with fully backwards-compatible upgrades to the language.

[ Parent | on HN ]

Re:Rich client side web apps gone too far (2014) by orangecat on Saturday March 28, 2015 @08:58PM (#9283446)

Unicode support out of the box

utf16 support, which isn't the same thing: https://mathiasbynens.be/notes/javascript-unicode

easy manipulation of strings, arrays, and dictionaries

JS objects aren't dictionaries; all keys are coerced to strings, they lack basic operations like getting a list of keys or values, and iterating over keys can bite you if you forget hasOwnProperty.

Python comes pretty close, with slightly wonky scoping and Unicode bolted on

And equality operators that aren't utterly insane, a usable standard library, local rather than global scope by default, classes, namespaces, modules...

ES6 does look a like a large improvement. Mainly because it fixes misfeatures and adds capabilities that better languages dealt with years ago.

[ Parent | on HN ]

Re:Rich client side web apps gone too far (2014) by chase-seibert on Saturday March 28, 2015 @11:47PM (#9283794)

ES6 admittedly borrowed a lot from Python. I just wish Guido had been successful getting Python supported as a first class language in Chrome; that might have actually given us a choice in the browser. Even then, I find it hard to imagine that ALL other browsers would have followed suit.

[ Parent | on HN ]

Re:Rich client side web apps gone too far (2014) by mattdeboard on Saturday March 28, 2015 @07:28PM (#9283194)

Garbage collection is a function of the particular runtime, no? Which probably isn't anything to do with the language... right? I'm asking sincerely, these aren't loaded questions.

[ Parent | on HN ]

Re:Rich client side web apps gone too far (2014) by gingerrr on Monday March 30, 2015 @03:36AM (#9288085)

while the particular effectiveness of a runtime's GC is determined by the VM, JS the language doesn't provide operators or types to represent manual memory management - so it's a pretty core feature of the language that whatever VM it runs on will use garbage collection (or at the very least transparent automatic memory management) to reclaim memory.

[ Parent | on HN ]

Re:Rich client side web apps gone too far (2014) by gingerrr on Monday March 30, 2015 @03:31AM (#9288071)

the fact that "javascript sucks" wasn't the point of the essay is EXACTLY my point - in an article that should be about calling out bad practices in designing web client experiences, there are judicious sprinklings of criticism of the underlying language, without attempting to distinguish those harms from the harms of bad choices in implementation. that sort of conflation is intellectually sloppy and ultimately leads to both sides 'reflexively' responding.

I'll definitely agree that javascript has room for improvement, but i'm not sure by what objective standard you're measuring its design chops. If you consider the goal of JS to be an incredibly flexible, light language with powerful runtime dynamicism and a strong focus on client-only needs, I'd say it's fairly well-designed. If you're holding it up against python as a server scripting language, it probably doesn't quite measure up. and if you're holding it up against all other languages and measuring by some 'general-purpose utility' ruler, that's a pretty pointless exercise - as I said in my original comment, languages are designed to solve specific problems, and JS is no exception.

[ Parent | on HN ]