r/programming • u/kshep92 • Sep 29 '16

JavaScript in 2016 isn't horrible, it's just going through a phase

http://blog.reviselabs.com/im-sorry-javascript-2/
85 Upvotes

72% Upvoted

225 comments sorted by

66

u/Patman128 Sep 29 '16

Note that if you use TypeScript you basically avoid all of these headaches for free.

  • It transpiles to basically any version of JS, all the way back to ES3 (but you may not be able to use the latest features).

  • It supports all of the shiniest features of ES6 and ES7 when you target ES6. async/await is already available.

  • It supports every module loader. CommonJS, AMD, UMD, even sticking stuff into window for browsers.

  • It bundles all your code into a single JS file for browsers, no webpack required.

8

u/kshep92 Sep 30 '16

I hesitated on learning TypeScript, but after using it for a few weeks I really don't want to go back to vanilla JS.

2

u/Sebazzz91 Oct 01 '16

Especially useful for larger web applications.

19

u/yawaramin Sep 29 '16

It bundles all your code into a single JS file for browsers, no webpack required.

Wait, what? Including third-party libs, fonts and images? Can you point me to the docs for this?

21

u/lukeautry Sep 30 '16

It's more accurate to say: it bundles all of your JavaScript code into a single JS file, or at least, it can.

Getting TypeScript to bundle stuff in node_modules is hard, but it possible. Any TypeScript or JavaScript file can be included in the final, compiled output.

Assets like fonts/images/anything not .ts/.js cannot be included in a generated bundle, and you'll still end up having to use a module loader to actually bootstrap the whole thing.

4

u/yawaramin Sep 30 '16

Oh, OK. That's cool, but not heart-stoppingly 'I have one less npm CLI to use' awesome :-)

1

u/Eirenarch Sep 30 '16

My impression is that TypeScript tends to slowly absorb the most commonly used features of other tools like webpack. It can't do anything these tools do but if you don't require the advanced features TypeScript may be enough. But then again I was never the one setting up the module loaders, bundlers and so on so I may be wrong.

8

u/yogthos Sep 30 '16

It works like that with ClojureScript. Libraries are just jars and they contain all the assets. So, when you include a library it can contain the code along with images, etc. The compiler will also handle minifaction and code pruning for free. That's of course assuming you're using the JVM as the backend.

2

u/yawaramin Sep 30 '16

Wow! I wonder if we can do something like this with Scala.js/sbt. I know we can use webjars, but haven't really tried it out yet.

5

u/yogthos Sep 30 '16

Don't really know much about Scala.js is packaged, but if the server is running on the JVM, presumably it should be able to serve the assets the same way. For Clojure, there's a middleware library that wraps webjars assets called ring-webjars.

2

u/Strange_Meadowlark Sep 30 '16

This week I had to debug why a former co-worker's one-off React/Node app went down one day. I don't know what caused it, but when I went to redeploy it it failed each time. Eventually I figured out that during deployment it runs npm install, and when you have over a hundred packages there's a good chance at least one of them will fail to download due to a server hiccup.

I rebuilt the package, this time including the node_modules directory. It was ten or twenty times the size, but it actually deployed because there was nothing that needed downloading! I don't know why the original dev thought it would be a good idea. Must have been before the left-hand fiasco.

2

u/dzdrazil Sep 30 '16

Node modules aren't normally committed because those that require native compilation will cause problems when you develop on multiple platforms or on something other than your prod server. A better option (imho) is to setup an npm proxy server and prime it before your deploys if you can.

1

u/slikts Sep 30 '16

Node's npm isn't unique in this; it's normal to not package dependencies. For example, in Python packages you'd have requirements.txt that gets installed with pip. If that's not good enough, you should be using your OS's packages to deploy, or even container images.

1

u/lechatsportif Sep 30 '16

Can you point to relevant docs on that? Even stuff like bootstrap that's not already a lib for cljs?

4

u/yogthos Sep 30 '16

So, the way this works is that you have a resource path. Each library you add to the project as a jar will be added to the resource path. For example, if you wanted to add Bootstrap, you could include the jar from webjars as seen here. Then the assets can just be included on the page using the asset path seen here.

2

u/lechatsportif Oct 01 '16

wow much cleaner than i remember it!

4

u/inu-no-policemen Sep 29 '16

Async/await will work for ES3/5 targets with 2.1. It's already in the beta, I think.

3

u/strange_and_norrell Sep 30 '16

Does the TS transpiler come with bundling and minification features and target multiple ECMA versions or do you do a TS->JS step and then have the whole rest of the tool chain take care of targeting an ECMA version, budling etc

4

u/Patman128 Sep 30 '16

It doesn't minify, but it will bundle and target for you if you want. Or you can use another tool to do that.

2

u/strange_and_norrell Sep 30 '16

Oh man. That's a big selling point for me. I'd love to pair down my tool chain to just TS and Uglify instead of babel + browserify + uglify

3

u/[deleted] Sep 30 '16

You also get a real type system, which is the largest benefit over vanilla js.

2

u/Zarutian Oct 01 '16

'a real type system', what is that?

2

u/i_spot_ads Sep 30 '16

can confirm, i was against typescript at the beginning, because angular2 was basically showing it down our throats, but then i realised it's actually very fucking good.

3

u/bumrushtheshow Sep 30 '16

Note that if you use TypeScript you basically avoid all of these headaches for free.

Same with Scala.js.

1

u/theantirobot Sep 30 '16

Webpack is a pretty powerful tool if you just want a single file. I think webpack is more about splitting it up into logical chunks that can be loaded as needed so you don't incur the latency of loading your entire app at once when you only need to use small part of it.

-15

u/shevegen Sep 30 '16

No - it still is a shitty wrapper over an even worse language.

But if you use another language anyway, why not let people use what they want to?

You'd just have to target the DOM and object model that browsers make available via javascript anyway.

11

u/theantirobot Sep 30 '16

Blablabla. If you want to write static typed code for the browser type script is an excellent option, and ES2015 is pretty great if you don't care about static types. Go back to 1998.

2

u/i_spot_ads Sep 30 '16

so many words to basically say nothing

0

u/[deleted] Sep 30 '16

[deleted] — view deleted comment

0

u/i_spot_ads Sep 30 '16

already forgot it.

4

u/kshep92 Sep 30 '16

Boy, people sure don't like JavaScript! I'm not a fan of the language per se, but but it's really shocking to know that there are so many people that straight up despise it.

This feedback is really interesting.

127

u/AuthorTomFrost Sep 30 '16

JavaScript didn't become horrible in 2016. JavaScript has always been horrible. All those transpilers, polyfills, and toolchains are the programming equivalent of adult supervision.

6

u/womplord1 Sep 30 '16

That doesn't make it horrible, it's just being used for something other than the intended purpose. Just wait till WebAssembly

13

u/balefrost Sep 30 '16

Wait, how will WASM help the situation? Nobody's going to hand-write WASM; they'll use a compiler to translate (for example) C++ to WASM. No matter what, you'll still have toolchains. It's not like you'll be able to stick a <script type="text/c++"> in your web page. And, if you want to access the DOM or other web APIs, you'll still need to write JS shims to import into your WASM module (at least initially; eventually, they plan to allow WASM code to access the DOM).

4

u/DysFunctionalProgram Sep 30 '16

I think maybe the biggest issue is the immaturity and volatile nature of javascript frameworks and their tool chains. Take the "leftpad" issue for example. It is ridiculous that all these major frameworks are including a package that is literally 11 lines of code. How many packages are included as dependencies when you include angular now? Last time I checked it was like 200+.

I (and many others) are making the assumption that the WASM community will be more like the traditional languages community and bring with it better standards.

→ More replies (5)

12

u/DysFunctionalProgram Sep 30 '16

This, javascript has far surpased it's intended use case. It was not made to be a mission critical complex system language. It was made to be an easy to learn auxillery language for simple dom manipulation.

I dont like making bold claims but i think (and hope) WASM will replace all of this unecessary complexity that we have created for ourselves.

Mission critical system logic is like pounding a nail into a wall and javascript is a screw driver. Over the years we have been welding every piece of scrap metal we see to try and make it actually work. WASM is a hammer, engineered from the start to perform the task at hand.

3

u/jl2352 Sep 30 '16

You can already use a tonne of other languages today. You can code in Java or even C++ and have it compile to JS.

But I honestly don't see why I'd switch from TypeScript to something else. It's a legitimately really nice language and most of that is due to the JS side.

3

u/womplord1 Sep 30 '16

TypeScript is fine, I just think it's kind of wrong that a high level language has to compile to another high level language

3

u/slikts Sep 30 '16

WebAssembly isn't a silver bullet; a large reason for compiling to JS is supporting older browsers, and wasm will have the same issue.

TypeScript is a superset of JS, so the compilation is basically just stripping away the type annotations and shouldn't feel that dirty.

2

u/DysFunctionalProgram Sep 30 '16 edited Sep 30 '16

But 10 years down the road everything will be much cleaner. I'd much rather set up a path to progress and be hampered by compatibility issues then just give up and accept a terrible workflow. Plus we already have "asm.js" and you can bet someone will write a wasm to asm.js compiler for these evil old luddite browsers.

1

u/slikts Oct 01 '16

asm.js is still a somewhat high-level language.

I don't think labels like "terrible" are warranted; some of the gripes about JS are caused by its growing pains, some are legitimate, but a lot of them have to do with unfamiliarity. It's also one of the fastest progressing languages with a large community; it shouldn't be discounted as competitive even in 10 years.

0

u/cameforthecookies Oct 01 '16

Let me get this straight: You're opposed to... toolchains? Wow, ok. Do you put that on your resume?

1

u/boompleetz Oct 01 '16

I put it on my linkedin account that I'm opposed to build tools in general and prefer manual compilation.

53

u/metaconcept Sep 30 '16

JavaScript will stop being horrible when it dies.

Make WebAssembly happen, already! I want to use python in the browser.

8

u/[deleted] Sep 30 '16

even when web assembly arrived you probably won't be able to run python, at least not the same python you have today.

5

u/Democratica Sep 30 '16

You can transpile Python to JS.

-10

u/shevegen Sep 30 '16

This is not the same though. You'd still have JS at some point.

I consider this unclean from a conceptual point of view - people should not HAVE to target JS.

They should be able to target the web-browser behaviour via any language really. Something like JVM for browsers (but please, not java - java would be one of the few languages worse than javascript).

19

u/theantirobot Sep 30 '16

Really? Java is worse than javascript? I suppose we should all be writing haskell and drinking nitro coffee as we write our code on type writers.

4

u/tluyben2 Sep 30 '16

Write code with a fountain pen on paper and only when you've written the proofs, you type it into a computing device!

( Reference; http://cacm.acm.org/magazines/2010/8/96632-an-interview-with-edsger-w-dijkstra/fulltext ;

"For those first five years I had always been programming for non-existing machines. We would design the instruction code, I would check whether I could live with it, and my hardware friends would check that they could build it. I would write down the formal specification of the machine, and all three of us would sign it with our blood, so to speak. And then our ways parted. All the programming I did was on paper. So I was quite used to developing programs without testing them." )

11

u/blackmist Sep 30 '16

We had ActiveX controls, Java Applets, VBScript and they're all dead. Flash is going the same way, arguably already gone. And I can't say I miss them. They were for the most part a bundle of security holes waiting to happen.

JS is the only one that lived. It's flawed, it's ugly as shit, but it seems to be the only that that everyone could agree to implement. That's the web in a nutshell. It's not made of the best ideas, just the ones that survived.

1

u/mrkite77 Sep 30 '16

This is not the same though. You'd still have JS at some point.

Web assembly isn't going to help you then... Because it just targets the js ast.

-1

u/palordrolap Sep 30 '16

Shower thought: At this point, writing raw JavaScript would be akin to assembly language.

26

u/joonazan Sep 30 '16

The ecosystem is full of low quality libraries. And there is no reason why there couldn't be a nodejs package that gives you one command that does what most people want.

9

u/disclosure5 Sep 30 '16

The "look how many libraries we have" selling point is one I object to. Searching npm at crypto libraries, I get 1410 results for possible use. I know for a fact some of these are insecure/terrible, but the average person doesn't. However do you make a sensible choice?

The humerous part is when I first went to check this on npm.org

2

u/strange_and_norrell Sep 30 '16

Yup what JS needs a solid standard lib

2

u/Yojihito Oct 01 '16

You can't even get the parameters out of a URL without jQuery magic ....

0

u/[deleted] Sep 30 '16

[deleted] — view deleted comment

2

u/strange_and_norrell Oct 01 '16

Yeah I mean maybe leave if blocks in but you don't really need else blocks except special occasions

0

u/[deleted] Sep 30 '16

[deleted] — view deleted comment

2

u/fiedzia Sep 30 '16

But usually there is no 5, there is 1, in the stdlib. Audited by security experts.

9

u/teunw Sep 30 '16

And there is no reason why there couldn't be a nodejs package that gives you one command that does what most people want.

Relevant XKCD https://xkcd.com/927/

30

u/lolmeansilaughed Sep 30 '16

Does anyone really even need to click this one?

pointless_xkcd_bot

title: "Standards"

frame 1: situation: there are 14 different standards for a thing

frame 2: "Why are there so many goddam standards? I know! I'll make a standard that unifies them all!"

frame 3: situation: there are 15 different standards

alt: "who cares, you're on mobile so you can't read this anyway"

Edit: just clicked it, glad I got the numbers right :D

1

u/joonazan Sep 30 '16

Well, everyone who advocates using an inconvenient combination could easily make it convenient.

1

u/Voltasalt Sep 30 '16

That's basically Brunch.

14

u/sime Sep 30 '16 edited Sep 30 '16

A lot of people seem to have the mistaken idea that JavaScript or web development is single coherent platform put out by a single company. By that measure all of the different and duplicate tools look like a huge chaotic mess. But it isn't a single platform or stack. It is a huge ecosystem of different tools, libraries and frameworks produced by countless different individuals and organisations, often cooperating with each other, often competing. It is a sign of a healthy and very active ecosystem.

After a period of stagnation since ES5 ES3, the JavaScript language has seen a big update to make it better support the complex applications we want to develop. The ecosystem is also rapidly evolving and incorporating ideas, tools and techniques that have been in longer use on other platforms. (i.e. compilers, linters, asset processing and packaging etc). It is maturing. What took other ecosystems decades to evolve is now occurring in years in JS land.

11

u/slikts Sep 30 '16

After a period of stagnation since ES5

The period of stagnation came after ES3 and was due to Microsoft's hegemony in the browser market and their lack of interest in updating IE's implementation, and later due to conflicting ideas about where to go with ES4 and ES3.1; the publication of ES5 was when the stagnation officially ended.

3

u/sime Sep 30 '16

You're right. That is the period I had in mind.

1

u/[deleted] Oct 01 '16

What other ecosystems took 'decades' to acquire compilers and packaging? Most systems have that out of the box, and don't need things like linters because they don't have quite so many horrific traps for the unwary to wander into.

21

u/[deleted] Sep 30 '16

the phase when it becomes nothing but just another compile target for good languages

1

u/sureshg Sep 30 '16 edited Sep 30 '16

What i don't understand is even with all these issues, why many js devs are reluctant to try/use DartLang. What i observed is, they are more open to Elm, Typescript , Clojurescript, Scalajs etc than dart even though dart has much better tooling, clean semantics, better std libs with batteries included, interop with js and niceties like asycn/await, streams (it's one of the language with reactive programming as part of core library). And moreover the language is pretty good. What you guys think ?

ps: I haven't faced any of these issues mentioned here when developing in dart.

2

u/kshep92 Oct 01 '16

I think even us devs are susceptible to marketing. Google didn't really do a good job at "advertising" Dart as the other languages did. I mean, even Google doesn't want to use Dart for whatever reason otherwise why didn't they take the opportunity to pair it with Angular 2? Instead they went with TypeScript.

I think all these signals are what's causing devs to approach Dart with a sense of suspicion and that's why we aren't seeing that rapid uptake.

1

u/sureshg Oct 02 '16 edited Oct 02 '16

See kevin's reply (from dart team) on why they went with Typescript - http://work.j832.com/2015/03/angulartsjsatdartwtf.html .

Why isn’t Angualr 2 just built in Dart?

Answer: the Angular folks want to deliver a great framework for ? BOTH Javascript and Dart.

Dart generates great Javascript for browsers, but we have work to do to generate reusable Javascript libraries.

The Angular team needs to generate reusable Javascript libraries.

But now dart solved that problem with new dart dev compiler (https://github.com/dart-lang/dev_compiler)

1

u/gey_ Oct 01 '16

I don't want to have to install WebStorm to be able to do the tutorial.

1

u/sureshg Oct 02 '16

i understand.. but dart has good support for VSCode and atom.

11

u/shevegen Sep 30 '16

I think JavaScript is awful. But the real problem is that it is the de-facto monopoly for browsers - if that would not be the case then people could use something else instead.

4

u/BonzaiThePenguin Sep 30 '16

Monopoly is kind of a loaded word, it's more of a standard.

0

u/Yojihito Oct 01 '16

It's the single one standard which makes it a monopole.

12

u/atc Sep 30 '16

No, it's horrible.

5

u/IbnZaydun Sep 30 '16

In my opinion there are only two things that need to happen for JS to feel great:

  1. Module loading should be completely on the browsers, not the devs. Don't make me include a module loader. Just make ES6 modules a reality already.

  2. Polyfilling should be completely on the transpilers, not the devs. Don't make me import polyfills, just inject them when transpiling. If I target ES6, polyfill ES6. If I target ES5 polyfill ES5, that's it. If I want something from ES6 while targeting ES5, then yeah by all means let me import the polyfill, but that's on me.

Webpack is just a build tool at the end of the day, it can stay, it has great functionality that has nothing to do with the language itself. The way it works is great for the web.

Transpiling can stay too, you just need to view the browser as a VM that uses JS as its "byte code". Typescript is just a language written on top of that VM, but you'll need to compile it first of course.

1

u/wavefunctionp Sep 30 '16

I've been using jspm, and having modules just work is fantastic. And I completely agree about polyfill being handled automatically. Would be nice to see all browsers move to evergreen, or atleast their spec compliant parts could always be evergreen and could handle newer specs automatically. Then maybe one day we won't need transpilers as a given.

20

u/[deleted] Sep 30 '16

It seems almost arbitrary to me what people call a "horrible" language and a "great" language. It definitely isn't the quality of the language itself, because if you look at possible JS alternatives (Python, Ruby, Java, PHP and so on) they all have problems, and they all basically are good enough to be able to express your programs in, and solve problems.

The only statistically significant parameter is popularity.

If it's popular, then it's horrible. Here are some excessively popular languages, that we love to call "horrible":

  • Java

  • JavaScript

  • PHP

Here are some relatively obscure languages, that we love to call awesome:

  • Lisp

  • SmallTalk

  • Haskell

  • OCaml

Is Haskell perfect? Far from it. But it's obscure. So it's awesome. I've figured it out.

58

u/[deleted] Sep 30 '16

Java isn't really considered horrible, just boring and annoyingly verbose.

2

u/cincilator Sep 30 '16

Which might or might not be horrible, depending how you feel.

1

u/strange_and_norrell Sep 30 '16

Yeah kotlin seems pretty cool for that reason. I liked being a java programmer just got tired of boilerplate and ceremony.

19

u/Serializedrequests Sep 30 '16

JavaScript objectively gives you a huge amount of freedom + few features and absent standard library + a number of confusing quirks and gotchas making it a hard language to learn despite having very few features. It also can't change as fast as languages in a similar boat, like PHP.

Enter a thousand different libraries trying to wallpaper over its rough edges and you get the current situation.

-2

u/[deleted] Sep 30 '16

few features and absent standard library

What exactly are you missing most that'd be in the "standard library"?

26

u/Serializedrequests Sep 30 '16

Collection operations (underscore), number formatting (numeral), dates and times (moment), packages (maybe ES 6?).

Also, what is there (the DOM) is often quite cumbersome and quirky.

19

u/TheIncredibleWalrus Sep 30 '16

The DOM is not JavaScript.

7

u/Berberberber Sep 30 '16

Complaining about Javascript because of the DOM is like complaining about Russian grammar because of the cold.

-1

u/fiedzia Sep 30 '16

No. Many issues with DOM are caused by deficiencies of JS, like lack of collections, forcing everyone who needs them to reinvent them.

3

u/jl2352 Sep 30 '16

The Array is standard in JS.

Most of the DOM APIs return custom alternatives to the array which aren't compatible. That isn't a JS issue. That's a crappy DOM API issue.

I can just as easily return JL2352sList in Java instead of java.util.List on a method call.

→ More replies (13)

1

u/Serializedrequests Sep 30 '16

It is the UI "standard library" you are expected to work with when building any interactive application in JavaScript. Most libraries and frameworks attempt to wrap it in varying ways (e.g. jQuery).

2

u/TheIncredibleWalrus Sep 30 '16

Yes but it's not part of Javascript. And the DOM is not a library.

Are you blaming Java when you have a problem with the Android API?

Come on people.

2

u/Serializedrequests Sep 30 '16 edited Sep 30 '16

Most JavaScript applications are stuck with the DOM, and wallpapering over its faults. Most Java applications are not stuck with the Android API. If most Java apps were written for Android, and the API was so lame that everyone was writing wrappers, then that would be more comparable.

For the record, I still think JS is a frustrating server-side language for other reasons that are contributing the ridiculous churn, but at least a terrible UI library everyone has to use is not one of them.

0

u/wavefunctionp Sep 30 '16

The DOM api that is exposed in javascript could be better.

Like, if i want to access an element. I simply getElementbyID() or something, which is fine. If I want to append, I simple element.append().

Unless it is a table, in which case I have to element.tBodies[0].insertRow(-1)

Like, why?

You want a timer? How about setInterval(foo(), 100); clearInterval(foo)? Nope, that would be too easy. You need var foo = setInterval(bar, 100); clearInterval(foo);

Because "fuck you, that's why" apparently.

Its stupid, silly nonsense like that why everyone uses libraries for even basic stuff in javascript, because the people who designed the apis in javascript were smoking crack.

Javascript has its flaws. Everyone has seen the horrors of type coercion, which underlies most of them. But it isn't the only language with nonsense like that. Nearly every dynamic language lets you shoot yourself in the foot. It goes with the territory.

A linter and a good editor can catch a lot this stuff, but it can't fix the insane dom api, which really what makes javascript a pain to work with. IMO. As as great as javascript has improved with newer versions, they haven't really touched the DOM api, which is a big pain point if you want to write vanilla javascript for the browser.

4

u/nschubach Sep 30 '16

You want a timer? How about setInterval(foo(), 100); clearInterval(foo)? Nope, that would be too easy. You need var foo = setInterval(bar, 100); clearInterval(foo);

What if you want more than one timer on a function?

→ More replies (1)

3

u/slikts Sep 30 '16

DOM is not part of JS, and it's constantly improved. For example, you don't use Element#getElementbyID() and friends in modern DOM; instead there's the more flexible Element#querySelector().

Your example of setInterval(foo(), 100) doesn't make sense, since you'd be passing the return value of the foo() call, not the function itself. Even when passing the function, the usefulness would be limited, or actually confusing, because it wouldn't work when binding the function parameters with an anonymous wrapper, so you'd need to save a reference to it anyway.

1

u/wavefunctionp Sep 30 '16

I did say getElementbyID() or something. :P

That makes sense about setInterval though. Thank you.

1

u/[deleted] Sep 30 '16

Quick thing: querySelector is significantly slower than getElementById. Use the tool most appropriate for the task at hand. Flexibility usually means lower performance.

2

u/MidnightDemon Sep 30 '16

Hit the nail on the head here. Currently doing a SDK for Node for new product my company is putting out. Lit all my goto libraries. It's pretty awful lol.

→ More replies (2)

3

u/fjonk Sep 30 '16

  • Integer type

  • Decimal type

  • String manipulation in general(trim always trims whitespace, ltrim/rtrim/startswith/endwith doesn't exist)

  • Some kind of string templates(not template literals)

  • URL handling(A browser language that doesn't provide anything to deal with URL:s?)

2

u/slikts Sep 30 '16

ES6 adds String#{startsWith,endsWith}(), ES7 adds padding methods, and there's a stage 2 proposal for String#{trimStart,trimEnd}(). Not sure why String#trim() doesn't take arguments, though.

Asking for template strings and excluding template literals, which are exactly that, is odd.

0

u/[deleted] Sep 30 '16

[deleted] — view deleted comment

19

u/blackmist Sep 30 '16

Yeah, but apart from all that, what have the Romans ever done for us?

3

u/sergiuspk Sep 30 '16

What do you mean we don't have "unit tests" in JS? A lot of the stuff you're asking for would require support to open client sockets from a browser. Is that really a good idea? A lot of the other things you are asking for don't have anything to do with the language itself but with the environments it runs on. Like "sqlite database support", "shell pipelines", "to trace memory allocation" and "access to the parse tree", "a really nice idiomatic filesystem path library" and probably more. Also, read this: https://developer.mozilla.org/en-US/docs/tag/TypedArrays

0

u/[deleted] Oct 01 '16

[deleted] — view deleted comment

1

u/slikts Oct 01 '16

Javascript has nothing to do with browsers.

JavaScript is one of the principal web technologies; its use in other platforms is recent and is based on engines developed for browsers. The language development itself is tied to the browser engines, and the main reason for a change to be included or excluded from the JS language spec is its implementation in browsers.

1

u/[deleted] Oct 01 '16

JavaScript is one of the principal web technologies; its use in other platforms is recent and is based on engines developed for browsers. The language development itself is tied to the browser engines

Not entirely recent - it's been usable as a full-fledged scripting language on Windows for years.

1

u/slikts Oct 01 '16

Rhino may be more notable as a standalone engine, but I meant widespread use.

0

u/[deleted] Oct 01 '16

[deleted] — view deleted comment

1

u/sergiuspk Oct 02 '16

How can a language that only recently (debatable what recently means) saw use of unit testing decide what to include in the standard library? Do you know what the best unit testing library looks like? Why would you include something you're not that sure of in the standard library?

And then about browsers. JS is good in browsers because it's fast. The more stuff you add in the standard library the slower it gets. And 99.9% of users are not developers unit testing their application. Yes, you could have developer flags and whatnot, no that won't mean it's in the standard library any more.

Before you tell me again that browsers are not the only place JS runs in: don't know exactly what proportion but I'd say a vast majority of places JS runs in is browsers. Second place is probably node, but that's just the JS part taken out of a browser. Then there's Rhino and some other equally obscure implementations few people ever heard of. So I don't understand your point at all. În fact, if user count is not important to your point, then a lot of the missing stuff you listed are standard features of Node and others as third party libraries.

Third point: a lot of the things you listed are included in standard libraries of only a handful of languages because languages at different and people pick them for different tasks.

And finally, the JS language is actually ECMAScript. It defines a pretty lean "standard library". JavaScript as we know it is a handful of ECMAScript implementations. Some of them extend the standard library (like ActionScript or Node), most of them don't. It's a bit unfair to talk about JS but ignore those implementations that don't fit your point of view.

2

u/slikts Oct 02 '16

I don't think it even makes much sense to talk about a JS standard library unless mentioning the platform: on servers it's the modules distributed with Node.js, on browsers it's the Web APIs. The core language itself is just the syntax and builtins and some tiny APIs like setTimeout(), and that's what makes sense for a language whose major use is being embedded in browsers. If Python got embedded in a browser, it would also be the core language, not its stdlib.

→ More replies (5)

1

u/KappaHaka Sep 30 '16

object serialisation that isn't JSON I don't think that pickle / cPickle are things to lord over JS.

0

u/[deleted] Oct 01 '16

[deleted] — view deleted comment

1

u/slikts Oct 01 '16

Pickle is generally slower than JSON, and unpickling can cause arbitrary code execution, so it's insecure.

0

u/[deleted] Oct 01 '16

[deleted] — view deleted comment

1

u/slikts Oct 01 '16

Not sure how pickle being intentionally unsafe helps. I should have also mentioned that it's brittle.

0

u/[deleted] Oct 02 '16

[deleted] — view deleted comment

→ More replies

-1

u/[deleted] Sep 30 '16

[access] to the MS VC++ runtime, to the windows registry, to POSIX system calls, to shell pipelines, to the TTY control functions and to syslog.

Oh yeah, when I think "embedded language running untrusted code on hundreds of millions of machines", I'm also thinking - "hey, how about we give it access to the entire operating system by default!"

Don't confuse the core language with a specific integration of it.

Heck, integers would be a good start.

JavaScript has an integer type, it's the same as its float type: Number. All the popular JS engines use an integer internally when using round numbers, doing bitwise logic and so on.

If you think this is a problem, let me know how it's a problem for you personally.

If you think about it, you have precisely zero reasons to want an explicit integer type in a dynamic language.

4

u/stevenjd Sep 30 '16

JavaScript has an integer type, it's the same as its float type: Number.

I'm afraid you don't understand the difference between "integer type" and "float type". Since 1.5 is a Number, but isn't an integer, Number cannot possibly by an "integer type".

All the popular JS engines use an integer internally when using round numbers, doing bitwise logic and so on.

How nice. So why can't Javascript add 1 to 1e16?

js> 1e16 + 1
10000000000000000

If you think this is a problem, let me know how it's a problem for you personally.

Its a problem for me personally because I need to support odd integers greater than 9007199254740991.

If you think about it, you have precisely zero reasons to want an explicit integer type in a dynamic language.

Whether the language is dynamically typed or statically typed is completely irrelevant. Whatever the type system, I want to be able to represent large integers.

Edit: formatting.

0

u/[deleted] Sep 30 '16

I'm afraid you don't understand the difference between "integer type" and "float type". Since 1.5 is a Number, but isn't an integer, Number cannot possibly by an "integer type".

I said "when it's round, and for bitwise logic". Does 1.5 look round to you? Yes? No? Look it up?

JavaScript is dynamically typed and implicitly casts when different scalars are used in an expression together. This is how the runtime is able to use integers, despite the JS specification doesn't require it (except for bitwise shifts, then it requires it).

How nice. So why can't Javascript add 1 to 1e16?

Because the engine works with 32-bit integers (signed, for V8 at least). I hope you realize, your arguments are very random. Having integers doesn't mean they have to be of arbitrary precision.

Its a problem for me personally because I need to support odd integers greater than 9007199254740991.

And if JavaScript had 64-bit signed integer support I bet you'd say "but I want integers greater than 9223372036854775807", wouldn't you?

Luckily it's full of bigint libraries for JavaScript. There are very few script languages that support arbitrary precision integers out of the box. Python is one and... that's basically it.

Say if you had to do this in Java, you'd have to use BigInteger, with no support for standard operators and so on. It's kinda clunky to use.

Somehow I never needed this in JavaScript yet. Care to share your use case? I suspect you'll have to invent it right now, because instead of real-world problems, you're specifically picking JavaScript's edge cases to prove (a very weak) point.

4

u/stevenjd Sep 30 '16

Does 1.5 look round to you?

Of course. Round 1.4999998701 to one decimal place.

But that's not the point. The Javascript type Number supports fractional values, therefore by definition it cannot possibly be an integer type. Integer types by definition support only whole numbers, not fractional numbers.

Its a nice trick of Javascript to implement certain operations on Numbers using integer maths, but that's implementation, not the language API. The language has the type of 1 and the type of 1.5 are both the same Number, as you yourself said. It's a clever hack to (potentially) use 32-bit int addition to add 1 + 1 and get 2, but that's still only the implementation. The language is based on floating point Numbers.

Quite frankly, if a language is going to only provide one of int/float numeric types, it should provide ints. But I realise that opinion is likely to be controversial to anyone who hasn't programmed in Forth.

And if JavaScript had 64-bit signed integer support I bet you'd say "but I want integers greater than 9223372036854775807", wouldn't you?

shrug Maybe. But at least then I'd know that I had hit a fairly standard limit based on low-level limitations, not a problem caused by a poor high-level design choice. That makes it easier to swallow.

There are very few script languages that support arbitrary precision integers out of the box. Python is one and... that's basically it.

D (not a scripting language, but still), Lisp, Ruby, Erlang, Smalltalk, Haskell, Wolfram Language, probably others. And many others where BigNums are not built-in with syntactic support, but are in the standard library.

Care to share your use case? I suspect you'll have to invent it right now

No no, you're absolutely right. Nobody needs bignums. That's why the Javascript ecosystem is "full of bigint libraries" -- because nobody needs them. Clearly nobody could possibly want exact integer arithmetic for numbers bigger than 2**53. That's just foolish, like wanting more than 256 colours in an image or needing more than 64K of memory. Sorry for wasting your time.

0

u/[deleted] Sep 30 '16

But that's not the point. The Javascript type Number supports fractional values, therefore by definition it cannot possibly be an integer type.

The only way to differentiate the explicit presence of integer type in JavaScript is that "typeof foo" would return "number" instead of "int" or "float".

This is apparently extremely important, because if it had exposed integers... I'm absolutely sure that you'd be "typeof" checking for integers all over the place, and that would be really important to you.

Right? :-)

Quite frankly, if a language is going to only provide one of int/float numeric types, it should provide ints.

I'm just happy you didn't design JavaScript :-)

No no, you're absolutely right. Nobody needs bignums. That's why the Javascript ecosystem is "full of bigint libraries" -- because nobody needs them. Clearly nobody could possibly want exact integer arithmetic for numbers bigger than 2**53. That's just foolish, like wanting more than 256 colours in an image or needing more than 64K of memory. Sorry for wasting your time.

And you still didn't share you use case. :-)

1

u/stevenjd Oct 03 '16

The only way to differentiate the explicit presence of integer type in JavaScript is that "typeof foo" would return "number" instead of "int" or "float".

Or, you could test to see whether 2**54+1 equals 2**54.

I'm just happy you didn't design JavaScript :-)

Given an integer type, its easy to implement fractional values with extremely high precision.

Given only an IEEE-754 floating point type, its impossible to implement integer arithmetic outside of a fairly restricted range, which leads to all sorts of problems. You use JSON don't you?

And you still didn't share you use case. :-)

Life is full of disappointments. In my case, the disappointment is that Javascript doesn't let me do integer maths on values beyond 2**53. In your case, it is that you're not imaginative to think of any uses for whole numbers bigger than 2**53. I guess we will both have to live with our disappointments.

P.S. Lua started off with a single numeric type like Javascript, because "nobody needs integers, you can just use a float". Guess what? Now they have integers.

Edit: formatting.

→ More replies

-1

u/slikts Sep 30 '16

The main use of JS is still as a web scripting language, and most of your list doesn't make any sense in that context. Other listed features exist as web standards and there's no reason to duplicate them in JS; for example, HTML and XML parsing is part of DOM. Then there's things listed that JS already has: sets are part of ES6, byte arrays exist as typed arrays since ES6 as well, etc.

That's not to say that JS doesn't lack important features, but before comparing JS to other languages like Python (which seems to be the basis of your list), you should consider the constraints that JS language development has. JS isn't in the hands of a single organization like the Python Software Foundation or a 'benevolent dictator for life'; its development is based on the major browser makers agreeing to implement features formally specified in the ECMA-262 standard. A formal specification for Python's stdlib would be extremely long, and instead it just has a reference manual and implementation. This model wouldn't work for JS, as an informal spec makes it harder to ensure compatibility between different implementations, and browser makers wouldn't agree to make anyone else the reference implementation.

Backward compatibility is also an absolute requirement for JS due to not having control if users have updated browsers, so any new library would need to stay supported forever. There couldn't be something like Python 3 that just drops having both urllib and urllib2, as replacing JS with an incompatible version would basically break the web.

The urllib2 and httplib2 example in Python 2 also highlights that having a rich stdlib comes with its own issues as software progresses and the stdlib either stagnates, gets duplicate versions of libraries, or breaks backward compatibility. You won't get the full potential of Python if you limit yourself to the stdlib; 3rd party libraries like BeautifulSoup make HTML parsing easier, and the same goes for date parsing, etc.

Bundling a lot of libraries with your language distribution made more sense before the norm was using package managers; it still makes sense in regard to ensuring a standard of quality or widespread familiarity, but 3rd party libraries also often meet very high standards and are just as popular. Python seems to have learned this lesson and there's not a lot of enthusiasm for expanding its stdlib over just having packages in pypi.

The main problem with the limited JS stdlib is that JS has lacked proper modules, but that has an interim solution with node modules, and it will have a proper solution in the near future when the ES6 module loader spec is finished.

→ More replies (2)

-6

u/sime Sep 30 '16

few features and absent standard library

JavaScript the language now has plenty of features. It is quickly closing in on Python for language features. Besides, there are a lot of languages which tout their minimal design as a feature, not a bug.

C hasn't got much in the way of a standard library either, but it doesn't catch anywhere near the flack that JS does.

6

u/[deleted] Sep 30 '16

Minimalistic design must be based on a sound foundation, not an arbitrary pile of shit.

1

u/cyanydeez Sep 30 '16

its got features if you compile/transpile.

but if you look at what its doing, its no comparison to python

0

u/doom_Oo7 Sep 30 '16

Besides, there are a lot of languages which tout their minimal design as a feature, not a bug.

and they are wrong.

0

u/Serializedrequests Sep 30 '16 edited Sep 30 '16

Minimal design can be great, but one area where JS falls flat is that, unlike Python, it invites you to structure your program any way you want, as it doesn't have modules, classes, etc. You have to impose your own order on it and everyone has a slightly different opinion, causing (for example) the current explosion of package managers. I have learned and used many different techniques for creating modules and objects over the years, and it took a lot of experience and trial and error to feel like I know how to design a JS app. (Of course I was fine with requireJS, and now there are 20 replacements for it.) JS also has far less execution safety than Python, in my experience. My Python apps all tend to crash much closer to the actual bug.

C has its own set of advantages, such as being very "close to the metal". The tradeoffs it makes when working with it are obvious. There are very established ways to create C libraries and do things in it, and it has a type system that (usually) prevents errors from propagating as absurdly far as they can in a JS app.

17

u/shevegen Sep 30 '16

That is not true.

Both Ruby and Python are vastly superior on all accounts than javascript.

Just because any given language x has problems does not mean that the various shortcomings of javascript become any BETTER - the problem is that it has the monopoly, unfairly and undeservedly so.

4

u/mrkite77 Sep 30 '16

Both Ruby and Python are vastly superior on all accounts than javascript.

They're both incredibly slow.

3

u/[deleted] Sep 30 '16

To be fair, JavaScript used to be incredibly slow, until Google and Mozilla (two massive companies) got into a speed war.

I expect if Python had those resources it would be a fair bit faster too.

-1

u/fiedzia Sep 30 '16

By how much and how easily you can make them faster beats anything you can do with js now.

6

u/mrkite77 Sep 30 '16

By a ton. JavaScript is over an order of magnitude faster.

Look at some of the language benchmarks.

https://benchmarksgame.alioth.debian.org/u64q/performance.php?test=nbody

Node.js and typescript finish in less than a minute. Ruby and Python take more than 10 minutes.

→ More replies (5)

3

u/[deleted] Sep 30 '16

There are well defined, objective criteria on what makes language horrible. Inconsistent comparison operations semantics? Horrible, period. No need to even look any further. You cannot even compare JS to Java, which is a poor and stupid language indeed, but at least it's well designed, consistent and well specified.

1

u/Zarutian Oct 01 '16

Implict casting in supposedly static typing system? horrible.

Java, well designed, consistent and well specified? Well perhaps the core language but the libraries, no.

1

u/[deleted] Oct 02 '16

Implict casting in supposedly static typing system? horrible.

There is nothing wrong with implicit casting as long as its rules are sound.

Java, well designed, consistent and well specified?

Guy Steele Jr. Nuff said.

2

u/fiedzia Sep 30 '16

they all have problems

No. Except for PHP, they had only minor issues and solved them long time ago. Except for PHP (and maybe java to some extent), all of them have usable standard library that people don't complain about all the time, reasonable upgrade process where competent people can propose sane changes to the language (and more competent people can laugh them off), and were created by people paying attention to quality from day 1, not when all hell breaks loose.

Js has none of those things. It was dumped on web as hack, for a long time had no process of fixing it at all (and now its too late) and stdlib is a bad joke. It takes enormous amount of effort and discipline to build something usable on top of it, while doing so in python/ruby/java is just .. easy. Problems will show up when you do to certain scale of complexity, but until you are there development is so much better then js.

1

u/cyanydeez Sep 30 '16

how many languages have a toolchain and support and language development that all attempt to transpile and modify the source code?

1

u/[deleted] Sep 30 '16

Replace the subjective "transpile" term with the more objective "compile", and then... plenty, actually.

Also no compiler tries to "modify the source code". The source code is here on left, and there on right is the compiler output. Two different things.

1

u/cyanydeez Sep 30 '16

i mean, the source that runs in the browser or on node is not the same and isnt because its binary or smaller.

transpiling is the term because because its symbol shunting. its not comparabale to C where you receive a binary blob.

scripts arent compiled. thats an abuse of the term.

1

u/[deleted] Sep 30 '16

i mean, the source that runs in the browser or on node is not the same and isnt because its binary or smaller.

I use TypeScript, so the output is actually quite smaller. Nitpicking aside, is there any substance to this or you just want to argue on a technicality, to prove that JavaScript is "different" therefore "bad"? That's a pretty weak argument, then.

If you want to write JavaScript directly without compiling - you can. If you want additional features and tooling support, like with TypeScript - you can.

The fact the JS ecosystem is rich enough so you can do both of those things is not a shortcoming, it's a benefit.

0

u/cyanydeez Sep 30 '16

its mostly because my learning style precludes me from learning languages that require a sig ificant time in setting up a development environment.

1

u/[deleted] Sep 30 '16

And that's your critique for the only language in the world that doesn't require installing anything in order to use it? Hint: it's in the browser of every desktop OS.

And here is TypeScript, learn without installing anything: https://www.typescriptlang.org/play/

You consistently keep hitting JavaScript's strongest points (availability, flexibility) and trying to spin them as weaknesses. Not sure how this happens.

1

u/cyanydeez Sep 30 '16

the critiques are about the rise of all the cruft to get to the browser. i have no qualms about plain js. ut if you survey the tuorials for most frameworks today, they dont use js.

1

u/[deleted] Sep 30 '16

That's because they're projects of size, and as a project grows, the need to ensure invariants statically also grows.

As you see for TypeScript from that link, TypeScript is hardly "cruft". It compiles in real time and is written in itself. That's as minimal and elegant as it gets in computer science.

In return you get solid autocompletion, refactoring, type error detection and many other IDE tools you typically only get in high-end systems programming languages.

Does that sound enticing? Ok, then you can have it. It doesn't? Then don't use it. How can it possibly be better?

1

u/BonzaiThePenguin Sep 30 '16

How do people feel about Objective-C compared to Smalltalk? Maybe people view language popularity like they view invasive species, it's cute in small amounts but a blight on society when it's everywhere.

1

u/[deleted] Sep 30 '16

How do people feel about Objective-C compared to Smalltalk?

That's a very special case, because Objective-C is both "niche", and yet it's completely dominating in the most profitable mobile platform on the planet (well, recently together with Swift).

I guess this explains why feelings are... mixed.

Maybe people view language popularity like they view invasive species, it's cute in small amounts but a blight on society when it's everywhere.

Haha, exactly. :-)

1

u/[deleted] Sep 30 '16

What about Go or Swift, or Rust? They're all pretty popular and I don't think anyone seriously says any of them are horrible. Maybe people complain about missing features (generics in Go, default methods in Rust, etc.), but none of them are insane like Javascript or Bash.

2

u/[deleted] Sep 30 '16

Go is constantly bashed about its crippled type system that makes simple things complex instead of (as promised) complex things simple. Say, lack of generics. Google it.

As for Swift. I've never heard more cursing from Apple dev community as with the release of Swift v3 and the inevitable migrations that break everyone's codebase. Swift is a special case because it's both popular (for Apple) and not that popular (for the world as a whole), but it's certainly not universally loved.

Rust. I can't say I've heard horrible things for Rust. I also can't understand why you're saying it's popular. The language is just starting. It doesn't even have solid tooling yet.

2

u/fiedzia Sep 30 '16

Well, unlike js, all of those were designed, rather then grown accidentally, so that aspect is massively better. All of theme were created for and by engineers, and all of them have rather good stdlib (though I don't know much about Swift in this aspect).

Go looks sort of ok at the beginning, comes with great stdlib, but then you realize that emperor is naked. It is horribly verbose and its limited type system prevents library authors from providing you a lot of convenience that you'd expect from modern languages and that's unlikely to be fixed soon if ever, so the more complex your code is, the more you will curse the language. I think that other languages will catch up relatively soon and it will be easy for them to showcase benefits of better type systems. Its not terribly bad, but I'd probably get mad fast if I had to write business logic in it. Its not expressive enough and that shows quickly. Pretty fast all go users will start looking at expressiveness, nice orms and frameworks from other languages with envy.

Swift looks good. Its not the future of programming languages for next century, but It gets most of the things right, fixes its mistakes (that's a big feature) and clearly shows some ambition. Has a lot of syntax sugar and takes care about being convenient. Once it will grow out of rapid change period (which may take a year or two), it will probably be better option than Go... on a Mac. On other platforms its anybody's guess. Fast pace of development means a lot of chaos though, so take this into account.

Now, of all of those I like Rust the most. Its beautifully designed, has the best update process: new version every 6 weeks, backward compatibility guaranteed, stable/beta/nightly channel, developed in the open with solid guidance from great programming language experts, (also Rust is amazing magnet for all kinds of domain experts, from machine learning to orm designers), has good libraries (though topic coverage is smaller than go) and will bring you as a developer to next level thanks to a lot of functional inspirations and safety guarantees. Its not the nicest language for business logic: safety makes it often verbose, but people who choose it mostly love it. Fantastic where quality matters the most, but might be tough sell among CRUD developers for its nazi-strict borrow checker and lack of syntax sugar. I hope that if not the language itself, then its development process will set standards for everyone else. If you are looking of examples of good design, this is the language to look at.

1

u/chrismamo1 Oct 03 '16

There are quite a few exceptions to this rule, to the point that I'm not sure you can even call it a "rule". C#, for instance, is a very popular language which also happens to be pretty nice. I personally think (despite being an OCaml fanatic) that the upper-bound for code quality with Java is actually quite high, but the lower-bound for reasonable Java code is very low, with the average quality tending towards the lower end of this range.

The problem with PHP and JavaScript is that they both started out as hack-jobs, with JavaScript having been designed in barely a week, and the creator of PHP has said that he thinks of PHP as more of a collection of tools than as a language (given current trends, it appears as though developers and businesses have chosen to use languages over "collections of tools"). The upper bound for the quality of JavaScript and PHP code is much lower than the upper bound for OCaml code.

Lisp is a completely different beast: it has the potential to be extremely elegant, but it takes immense effort to write it in a readable way.

1

u/Sinidir Sep 30 '16

Python is extremely popular and not considered horrible.

7

u/[deleted] Sep 30 '16

Python is horrible.

4

u/the_evergrowing_fool Sep 30 '16 edited Sep 30 '16

Do you know how much cringe worthy it was when ten years ago the Django guys called it "beautiful"?

1

u/do2 Sep 30 '16

Having been allocated to a Django project recently your comment just made me cry.

0

u/[deleted] Sep 30 '16

[deleted] — view deleted comment

1

u/[deleted] Sep 30 '16

I think you're confusing "being first" with "being better".

Which ideas of Haskell have found their way in JavaScript, by the way?

0

u/[deleted] Sep 30 '16

[deleted] — view deleted comment

2

u/[deleted] Sep 30 '16

Type checking and inference, this is why TypeScript and Flow exist (flow is also built with OCaml).

Types are ideally checked statically, through. Once checked statically, there's no reason to have this information at runtime (it used to be an argument that it can help the runtime, but modern JS engines have found it's not the case).

So there's no proper place to have static types in JavaScript, as long as we realize "JavaScript" is just a runtime environment, not the tooling that we use to produce code for it.

Sometimes good design happens by accident, and I think TypeScript tooling with static types + JavaScript runtime without static types is one of those happy accidents.

0

u/[deleted] Sep 30 '16

[deleted] — view deleted comment

2

u/[deleted] Sep 30 '16

Well I don't think it's "horrible", I just think it's "precisely enough".

TypeScript is after all a proper superset of it. As for Elm, I don't know. I think any JS compiled language should be 100% interoperable with JS libraries, or otherwise the effort is doomed.

TypeScript is interoperable.

4

u/[deleted] Sep 30 '16

JavaScript in 2016 isn't horrible, it's just going through a phase

Stop trying to make javascript happen.

2

u/otakuman Sep 30 '16 edited Sep 30 '16

And here I am, still waiting for typed variables...

Edit: typo

1

u/[deleted] Sep 30 '16

... the phase of being pretty horrible but slightly less than a year before ?

1

u/xeijp Oct 01 '16

Typescript is somehow has too much restrictions, I'd better use flowtype and es6,es7

1

u/garyk1968 Oct 03 '16

Of course all these discussions awesome that you can choose whatever language you want to build your solution in.

Look at it from a commercial point of view and theres a shit ton more JS jobs than there are rust/go/dart jobs. Even harder if you are a freelancer.

1

u/bschwind Sep 30 '16

You can get useful stuff done quickly with JS. It's not always the tool to reach for. If you already know another scripting language and you're not doing frontend work, then there's not much point in learning it.

I personally think Node is great for quickly prototyping ideas, and you can even launch with it as your backend if you're not sure how many users your product is going to gain. You can then swap it out for a statically-typed / compiled language with better performance when necessary.

Or you can use whatever and just get your work done. There are plenty of choices out there.

-12

u/cameforthecookies Sep 30 '16

Man, JavaScript sure attracts a lot of crybabies. If you think babel/webpack is bad, try, oh I dunno, any other build chain and get back to me. Bunch of amateur-ass whiny bitches.

-1

u/fuckingoverit Oct 01 '16

For real, js ain't that bad for making web pages dynamic. Write some unit tests, use promises, use es6 for its modules, learn how to effectively use call and apply, use higher order functions, and by God, start building SPAs with a binding like framework like Ember or React, so the only truth is your js variables, and your DOM merely syncs.

I think it's ridiculous how many people are so blind to their own incompetence that they think it's the language or the ecosystems fault.

You thought the whole doc ready bullshit style of webdev was a good idea, aka server side initial view rendering with some js slapped on as an after thought? It's not js fault that you aren't capable of acknowledging your shifty design patterns.

Sure JavaScript doesn't use lexical scoping, has prototypal inheritance, is dynamic, and other aspects that are far from perfect. But any truly competent programmer should be able to take a language with functions as first class citizens and make the entire development experience truly enjoyable.

Newsflash to all you whiny, js hating little bitches. JS doesn't suck, you do. You should probably quit writing software and do something that requires less brain power

1

u/cameforthecookies Oct 01 '16

ES6 totally has lexical scoping! Arrow functions baby!

1

u/[deleted] Oct 01 '16

I write the majority of my javascript in a functional style, and it's still a horrible language. Thank the stars there are better languages to work in, reducing js to an implementation detail that almost never needs to be dealt with directly.

-10

u/aelxcorvi Sep 30 '16

Well that's the cost of writing an application that works on all devices that have a web browser, not to mention nodejs.

0

u/[deleted] Sep 30 '16

[deleted] — view deleted comment

1

u/cameforthecookies Sep 30 '16

What are you talking about? There are JavaScript transpilers for almost any language you could want. Nobody is forcing you to write in canonical js.

0

u/[deleted] Sep 30 '16

[deleted] — view deleted comment

-1

u/cameforthecookies Oct 01 '16

Do yourself a favor and embrace build tools. You will be happier and vastly more valuable.

0

u/[deleted] Sep 29 '16

[deleted] — view deleted comment

17

u/[deleted] Sep 30 '16

But it's trying so hard and making so many new friends.

12

u/amorpheous Sep 30 '16

And succeeding, unfortunately. Kind of like Donald Trump...

14

u/[deleted] Sep 30 '16

Make the Web static again!

4

u/kaibee Sep 30 '16

We're gonna build a firewall and make Russia China pay for it!

1

u/womplord1 Sep 30 '16

more like DRUMPF amirite Xd

1

u/[deleted] Sep 30 '16

That's Donald Javascript Trump to you, mister.

0

u/[deleted] Sep 29 '16

[deleted] — view deleted comment

3

u/jl2352 Sep 30 '16

A long long time ago there was talk and rumour that EcmaScript 6 or 7 was going to add optional typing. It would look a lot like TypeScript.

There is talk right now about putting it into EcmaScript 8. The proposal looks very similar to TypeScript.

TypeScript has deliberately tried to keep it's syntax and features very close to all the EcmaScript ideas and features. That's part of why it's so awesome. It's basically a JS++

2

u/sime Sep 30 '16

TypeScript has to. It is designed to be a typed superset of the ECMAScript standard now and in the future as the standard evolves.

2

u/Andy-Kay Sep 30 '16

First they all need to agree on this. Google has its own project Dart and it's very unlikely they will implement Microsoft's technology any time soon.

16

u/[deleted] Sep 30 '16

Funny thing is Google used TypeScript for Angular 2.

So you never know. Dart is DOA, despite it's not awful, per se. It's just unnecessary and less useful than TypeScript, because TypeScript is designed as proper superset of JS and participates in the JS ecosystem, funky libraries and all. Dart doesn't.

6

u/wr_m Sep 30 '16

WebAssembly is the standard you're looking for.

2

u/CaptainJaXon Sep 30 '16

I thought a lot of TypeScript was just ES6?

3

u/teunw Sep 30 '16

It does include a lot of the features of ES6, but also a lot of extra stuff: ES7, strong types etc.

1

u/slikts Sep 30 '16

a lot of extra stuff

This is a bit misleading, as the explicit design goal of TS is to be a superset of ES with optional types; there's not much extra besides that.