Slashdot Mirror
ECMAScript 2016: New Version of JavaScript Language Released (softpedia.com)
An anonymous Slashdot reader writes: Ecma International, the organization in charge of managing the ECMAScript standard, has published the most recent version of the JavaScript language. ECMAScript 2016 (ES7 or JavaScript 7th Edition in the old naming scheme) comes with very few new features. The most important is that JavaScript developers will finally get a "raise to the power" operator, which was mysteriously left out of the standard for 20 years. The operator is **...
It will also become much easier to search for data in a JavaScript array with Array.prototype.includes(), but support for async functions (initially announced for ES2016), has been deferred until next year's release. "From now on, expect smaller changelogs from the ECMAScript team," reports Softpedia, "since this was the plan set out last year. Fewer breaking changes means more time to migrate code, instead of having to rewrite entire applications, as developers did when the mammoth ES6 release came out last year."
It will also become much easier to search for data in a JavaScript array with Array.prototype.includes(), but support for async functions (initially announced for ES2016), has been deferred until next year's release. "From now on, expect smaller changelogs from the ECMAScript team," reports Softpedia, "since this was the plan set out last year. Fewer breaking changes means more time to migrate code, instead of having to rewrite entire applications, as developers did when the mammoth ES6 release came out last year."
lots of knowledgeable people hate or dislike javascript, and have done so from the start, and give excellent reasons for their hate and dislike.
but it has succeeded in spite of them and these reasons, and is more or less an indispensable part of modern on-line world currently.
why? what did these 'knowledgeable' people missed or still miss when evaluating it?
The power operator will get used once by one guy, who will use it in this code:
export function pow(base, exponent) {return base**exponent;}
To use it, enter this command:
npm install js-power
Then, in your code:
const power = require('js-power');
let eight = power.pow(2, 3);
It's just that easy!
The only way JavaScript can be considered a "success" is if you define "success" to mean "used because it's the only option available".
But aside from that very limited view of "success", JavaScript is a total disaster.
It's a very broken language. Its type system is a wreck. It didn't have real class OO for ages, and even its prototype approach is shitty compared to Self. Its standard library is rubbish. Its syntax is mediocre. It is full of utterly stupid shit like semicolon insertion. It's a failure when looked at solely as a programming language.
Its surrounding ecosystem is also very broken. Numerous companies and organizations have had to pour huge amounts of money and other resources into it just to get JavaScript implementations that don't limp along at a snail's pace. It has also given us clusterfucks like Node.js and npm. Building anything more than an onclick handler using JavaScript rapidly becomes a huge debacle, and a maintenance headache.
Its community is among the worst there is. Something has to be pretty wrong with a community that thinks a language as awful and broken as JavaScript is worth celebrating! But I will give the JavaScript community credit, it isn't as terrible as the Rust community is. At least the JavaScript community's biggest offense is only ignorance. They aren't hypocrites who attack others with their tyrannical Code of Conduct, like we see some other programming language communities do.
JavaScript just isn't a success in any reasonable sense. It's a failure.
Actually for most languages I have used in the last 20 years, it is **. My son recently got into programming and his first programming language used ** as well. At this point I don't remember what language I learned that used ^. I remember in one language that was bitwise negation or something and never did what I wanted.
Secession is the right of all sentient beings.
Most of us with programming experience would expect 2^16 to return 18. I take it that you mainly use BASIC, right?
It's bitwise xor, in pretty much every language.
I still have more fans than freaks. WTF is wrong with you people?
We all expect 2^16 to return 65,536. Why make it something different?
No, I expect 2 << 15 to return 65536. The ^ is the XOR operator.
Having bitwise operators explained to you by JavaScript programmers must be a soul-crushing experience.
I don't see how locking between threads can work when their entire namespace is so mutable.
http://michaelsmith.id.au
In a few more years we'll have this turd polished to a mirror sheen! Maybe some day enough of the horrible design flaws will be undone and make it almost halfway comparable to a serious language.
Damn Straight
000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. DAMNSTRAIGHT.
000300
000400*
000500 ENVIRONMENT DIVISION.
000600 CONFIGURATION SECTION.
000700 SOURCE-COMPUTER. RM-COBOL.
000800 OBJECT-COMPUTER. RM-COBOL.
000900
001000 DATA DIVISION.
001100 FILE SECTION.
001200
100000 PROCEDURE DIVISION.
100100
100200 MAIN-LOGIC SECTION.
100300 BEGIN.
100400 DISPLAY " " LINE 1 POSITION 1 ERASE EOS.
100500 DISPLAY "Damn Straight" LINE 15 POSITION 10.
100600 STOP RUN.
100700 MAIN-LOGIC-EXIT.
100800 EXIT.
Here you go
http://michaelsmith.id.au
I'm pretty sure ** goes back to at least Fortran (though you may very well have seen it somewhere else). Javascript already uses ^ for bitwise XOR
JavaScript never does what is expected. This is a feature.
I just typed "2^16" into bc, and it returned 65536.
BC? Oh yeah, I remember- that was the most popular programming language Before Christ.
In Pascal, ^ deferences a pointer, as in recptr^.field = value. Some extended Pascal variants used ** as power operator.
When somebody makes this "argument", it's a sure sign that they've never actually used Python, and that they're just spewing bullshit.
Anyone who has used Python knows that this is totally a non issue. PEP 8 explains very clearly how to avoid and any all problems: "Use 4 spaces per indentation level."
That's all you have to do! Like it says, use 4 spaces per indentation level. It's as simple as that.
When somebody makes this "argument", it's also a sure sign that they've never actually used Python, and that they're just spewing bullshit.
Python has remarkably good backwards compatibility. A number of Python 3 features were actually backported to Python 2. And Python 2 still sees excellent continued support. Python 2.7.11 was released only about 7 months ago, just two days before the latest Python 3 release, 3.5.1!
Anyone who wants to keep using Python 2 can continue to do so. Those who want to use Python 3 are able to do so, too. And there's the excellent "2to3" tool which can quickly and reliably convert nearly all Python 2 code to Python 3 code. Hell, there are many Python libraries that support both Python 2 and 3 with ease!
I'm sorry, son, but you clearly don't know what the fuck you're talking about.
JavaScript is has been the language all browsers support, but why? Also why is it so bad? The answer to both questions is the same:
Because it was created in ten days. While Microsoft was scheduling meetings to discuss a proposal to plan a browser language, Brendan Eich created JavaScript (then called Mocha) and released it to the public. It was used because it was available, while other options were draft proposals, not yet approved for development, much less ready to use.
When you spend all of two days designing a language and seven days implementing it, you end up with a pretty crappy language.
The opposite end of the spectrum is Perl 6, which was designed from 2004 to roughly 2015. It's a rather nice language, for those who like Perl-like languages.
Cobol was designed almost 60 years ago. No doubt that if Cobol was created today, it wouldn't stand a chance. Fortunately Javascript is unlikely to resemble that fossil, ever.
Slashdot, fix the reply notifications... You won't get away with it...
Cobol was designed almost 60 years ago. No doubt that if Cobol was created today, it wouldn't stand a chance. Fortunately Javascript is unlikely to resemble that fossil, ever.
Modern Cobol might have a prettier syntax, but the language features itself are still rather unique and, for it's specific niche of batch programming, superior to alternatives. There are still very few language that can consistently beat Cobol on performance for batch programming.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
"ECMA"Script? I would love to adopt it, but I want my web site to be accessible from the UK.
^ is bitwise OR, just as it is in countless other languages, e.g. C, C++, Perl, Java, to name a few.
Il n'y a pas de Planet B.
Yeah, it's nearly as terse.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
This is where that pesky win10 upgrade actually helps web developers.
Win10 has "Edge", crap browser, but in terms of compatibility, we can stop worrying about fuckin IE 8, 9, 10, and 11... Bout damn time.
I was very much looking forward to await/async as a more mature way to natively provide clean synchronous wrappers for async code within synchronous code (and get around the nested hell of when/then). Please correct me if I'm wrong, but it only seems to be a future reserved word.
Right now, it appears I am still awaiting.
One reason ECMA can be so slow to release new features, is that they have no competition. If you want to write Web-based applications, you're stuck with JavaScript. There are no other viable options. Why should they be in a hurry to change things?
This is about to change. WebAssembly is coming. This is the development that will finally blow open the language barriers for browser-based programming. You'll be able to write client-side code in just about any language you already use and like, and you won't have to require the user to install some add-in to use it. Once this happens, it's quite possible that JavaScript will soon go the way of BASIC and COBOL.
To be fair, we (web developers) minify and compress everything, or atleast we should. You don't know who is on the other side of the connection, or what kind of bandwidth they have available so always try to cater to the largest target you can.
I also don't depend on huge JS libraries/frameworks, because I avoid JS if I can, but that's just me. Anything outside of basic DOM manipulation (show/hide elements, change this string to that value, etc) it just turns into a pain in the ass. I try to do all of the logic on the server side.
Unfortunately server side operations/logic falls flat when you try to do anything mildly interactive (games)... so I see where it would be very useful to have some kind of universal interface to utilize more than just ECMAScript/Javascript.
Yeah, you have to wait, that is ES7.
Democracy Now! - your daily, uncensored, corporate-free
The funniest part of this bullshit claim is that whatever you've supposedly done using Python, well, it likely depends on and uses the C and Python code I've contributed to the CPython implementation over the years! Son, you're out of your league.
Who cares? If you run Linux or streamed video you are probably using code I contributed, big fucking deal. In the end you are STILL posting AC, so you are by definition a bullshitter until proven otherwise. And WTF is with the "son"? Get your own voice, don't borrow it from whatever shitty media you borrowed it from. It helps your argument ZERO to sound condescending without any advantage.
You're the one who is out of touch, clearly. We serve compressed content these days
Not sure who "we" is, but web servers serve what browsers, CDNs, etc support. You'd be surprised at how many CDNs and embedded browsers have issues with compressions /w HTTP(S). To just "leave it up to someone else" as your solution implies is lazy, to say the least.
Or Python's bytecode could potentially be served up instead, were the browsers ever to support Python for client-side scripting.
But really in the end that's pretty much it. I can give you the benefit of the doubt that you have done a lot of work on Python, but it still means jack and shit in this context until someone actually DOES that. And they won't. Because Python is a decent language in some respects, but it's horribly shitty for this purpose.
Would you have preferred VBScript?
That's kind of a false dichotomy. I'm not saying that given the choice 20 years ago VBScript vs Javascript that I wouldn't have chosen Javascript, the question is since then why haven't we seen anything else? I'm still holding out hope for Python in the browser.
remove one ad from your site and you'll saved more than obfuscating the js file does.
despite this, compression is part of http for a long long time.
Obfuscation != minification or compression. Obfuscation is for making the Javascript harder to read (in an imperfect attempt to provide extra security or protect IP). Minification is for making the text smaller (though it's usually pretty good at obfuscating in the process), and compression is for making the transfer smaller.
so, then please debug an minimized script. Of course minifying obfuscates the script. And compression makes it unneccessary. That's the point.
Never built a site that had ads on it, so I'm not sure what the hell you're talking about.
No. You clearly don't do this stuff, so you really shouldn't be commenting on it if you don't know what you're talking about.
Minification makes the payload smaller. Compression is limited to gzip or deflate. If you compare original source compressed to minified source compressed the minified compressed will be smaller. Anywhere from 5-20% smaller in my own testing.
Some minification techniques will replace local variable names with smaller variable names, decreasing payload size in a way that compression cannot.
See Google's guide for more information: https://developers.google.com/...
I bet you visited one in your life ;-).
Now compare: a 500kb banner less or shrinking your js/css from a total of 50kb down to 30kb?
The banner is loaded dynamically, the css and js are cached for two weeks.
You see what i am talking about. And most ad systems need more than 500 kb of traffic nowadays
I think you did not really try it. Compressing a long variable name and uneeded whitespace is just as good as minification. A compression algorithm is optimized for making redundant data small and of course everything which can be minified contains redundancy, that's why you are able to shrink it.
And you're elegantly ignoring the other point, that your minified js file is cached for two weeks or something similiar. No need to use something minified.
A users first impression of a website is how quickly it loads initially. Caching doesn't help here.
I have tested Minification with Compression, and just straight compression. In all of my testing, Minification with Compression always wins. This is for both JS and CSS.
how big is your gain?
I would rather recommend to use less js, especially as it all adds processing time (which is normally single threaded in a browser ...)
A nice option is to replace a big jquery or similiar with http://vanilla-js.com/. Almost all functions you really need are already included, even those which needed jquery in the past.
I've already posted above that I don't use big libraries... really basic things like DOM manipulation, the odd modal window, and some iframe stuff.
As an example, a site I built recently for a local church has a single JS file called core.js. The original file is 14340 bytes. Compressed it is 3732 bytes. Minified and compressed it is 2792 bytes.
Another example, a project I built last year, is a web based document management system for an appliance manufacturers customers (dealers/retailers/distributors) to access product documentation (service manuals, marketing materials, etc), there is a total of 3 JS files. Each file is only loaded on pages it is needed.
portal.js - orig 7959 bytes - compressed 1971 bytes - minified/compressed 1636 bytes
rpc.js - orig 2088 bytes - compressed 819 bytes - minified/compressed 554 bytes
admin/docs.js - orig 1543 bytes - compressed 526 bytes - minified/compressed 405 bytes
Now these are pretty small files, as I've mentioned already I don't do very much JS. Some example CSS files from the document management system:
structure.css - orig 12589 bytes - compressed 2615 bytes - minified/compressed 2128 bytes
responsive.css - orig 7227 bytes - compressed 577 bytes - minified/compressed 433 bytes
forms.css - orig 5951 bytes - compressed 1262 bytes - minified/compressed 1097 bytes
For the record I use a fairly simple PHP-based CSS and JS minification classes to perform the minification. The compressed sizes are with 'gzip -9' compression.
You're talking about 300 bytes per file. What data rate do you expect your clients to have on average? How big is your smallest ad (or even the script loading the ad)?
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
That's what we're talking about. I am thankful when you try to save me these 300 bytes, but it's easier for example to stop using some barely related stock images in each article on a news site, costing 800kb to 2 mb, than cutting 300 bytes of a file, which is cached after the first visit.
Many people DO minification, but i think it's one of the most overrated optimizations out there.
You keep bringing up ads... I don't put ads on my sites. I develop web based applications for businesses, with the odd small business and community organization websites sprinkled in.
I've written a script that sits between static files and the web (or a CDN depending on the project) to automatically optimize all of these things for me, so I don't even have to think about it anymore, it just does it automatically.
The script also optimizes images (with optipng, jpegoptim, etc). It even goes as far to do image scaling based on a GET parameter (eg. ?scale=WxH) using ImageMagick. It automatically caches the optimized files and serves them up. It watches the file modified time of the original files to ensure whenever a change is made, the cached optimized files are updated on demand as well.
I am bringing up ads, because most of the "we need to optimize!" people are putting ads on their page, which are way bigger.
I wanted to bring up optipng, as its a lossless way to optimize. But i think the important load time has your assets cached. People coming from a search engine are used to wait 3-5 seconds. People clicking a link on your page, they should get the stuff from cache, so the next page needs less than one second. Server side scaling is useful. If you should use imagemagick (which is slow and insecure btw) or something like GD, i would rather have a set of sizes instead of doing it dynamically. You will not that often need width=101, so just use image_w100.png for it (and DO NOT scale it one the client).
And there we are at browser testing. for example mozilla browsers have a bad record on client side scaling of images. blink now has srcset to provide different sizes and as far as i have seen they scale images smoothly (down).
But on JS i still think the best performing script is the one you can remove from your site. Not everything needs to be 100% dynamic. I understand that mobile pages may want stuff like jquery mobile, but a desktop page with html and css is often just fine. Even "responsive" CSS is often rather annoying, when the site changes only because i resize the window.
I'm aware of all of this. I started developing web applications around 1998.
I use ImageMagick because in my testing it was faster at the time for bicubic resizing/scaling. I'm using the Imagick PECL extension, which mostly eliminates the security and speed issues as it wraps the library into a PHP extension. I've written it to never scale an image up. If you specify a height and width larger than the original file, you'll be served the original file... So someone smart enough can't fiddle and blow up images wasting server resources.
The point of having it dynamic is that I don't have to go out of my why (which interrupts my workflow) to fire up a graphics editor and make multiple scaled versions of an image. That, and 95% of the time the websites are operated and managed by whomever I create them for. Having a way to scale images for technically inept clients (that don't understand what a pixel is, let alone how you need to scale down pictures from your Canon camera before putting them on the web) is a huge time saver.
sounds reasonable ;-). I like imagemagick as well, but not for calling by scripts in most cases. php/perl libgd has some disadvantages, though. I like python's pillow.
Kill JS and put python in the browser: http://www.brython.info/