[cm2187]

I think it's rather that the java and .net framework are pretty good out of the box. So there is only a need for additional framework for certain corner cases. And then some get bought by Microsoft and integrated out of the box, like the datavisualization libraries or xamarin.

JavaScript on the other side is a language that only its conceptor could love. All these frameworks are sort of required to be barely productive. Which is why you end up with these big frameworks to abstract the various browsers, introduce databinding, or add static typing.

[douche]

Javascript has a terrible embarrassment of a standard library. Things that should just be baked into the language are not, which has lead to attempts to rectify that shortcoming, like jQuery, Underscore and LoDash. Because this standard library isn't implemented in the browser itself, where it belongs, people have gotten upset about downloading a few hundred kbs of a general purpose utility library, and instead reimplemented different bits of it in a thousand and one ways, nearly all of them more or less subtly broken. (I don't understand the obsession with JS library size - it's completely irrelevant in 95% of cases, compared to the megabytes of other garbage most sites will pull in for trackers and images).

[cm2187]

And not just in javascript. HTML is largely the culprit too. A lot is done in javascript that HTML should really handle.

For instance why can't we just add a URL attribute to an input to provide autocomplete and validation. It is such a common scenario there shouldn't be a need for a javascript framework to provide that.

Same thing with responsive design.

But these technologies are stuck in the 90s and barely evolve anymore.

[krapp]

>For instance why can't we just add a URL attribute to an input to provide autocomplete and validation.

You can. <input type="url" /> is part of HTML5[0].

Of course, support may not be universal[1], which is why you will probably always have to use javascript if cross-compatibility matters.

[0]https://www.w3.org/TR/html-markup/input.url.html

[1]http://caniuse.com/#feat=input-email-tel-url

[cm2187]

No by URL I meant the URL of the service that would provide the autocomplete or the validation. Like:

  <input type="text" validation="url1" autocomplete="url2" ...

[telotortium]

I'm not sure how either of these would help:

- validation: Fundamentally, to be able to trust the input, the server needs to validate it in its final state. The only reason validation should be done on the client is to reduce the latency from the time the user inputs the data to the time the validation result is reported, so the user can fix their input faster if it fails validation. Sending it to a URL before form submit doesn't make sense when the input will have to be validated after form submit anyway.

- autocomplete: It's unlikely that implementing this in native code will be faster than in Javascript. It's not significantly faster to make an HTTP request in native code -- native code is more advantageous for heavy computation, graphics, and multithreading. And yet, it's easy enough to make HTTP requests from Javascript that an autocomplete attribute wouldn't add much value.

[cm2187]

Being faster is not the point. Having to rely less on javascript libraries and more on the built in framework in the point.

And client side validation is not a substitute for server side validation, merely a better UX.

[carsongross]

I have a library that attempts to improve the power of HTML:

http://intercoolerjs.org

[dwaltrip]

Javascript library size matters a lot on mobile. If I'm recalling correctly, a huge app can take seconds just to be fully parsed on many phones. There are dozens of millions of people who are using budget android phones that do everything thing they need, but don't handle heavyweight pages super gracefully.

[agnivade]

FWIW - The new ES2015 spec has a lot of features baked into the runtime which otherwise would have to be handled by underscore. - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Of course, its not exhaustive by any means. But your general everyday stuff is covered.

[zbjornson]

Ehh... When there are many questions on SO asking how to read a file in Java and the answers all require about a dozen LOC and have hundreds of upvotes [0,1,2] I think I agree with the earlier comment that it's more a barrier to distribution and acquisition of modules. There are plenty of tiny npm modules that do less than a Java wrapper for easily reading files would.

[0] http://stackoverflow.com/questions/4716503/reading-a-plain-t... [1] http://stackoverflow.com/questions/326390/how-do-i-create-a-... [2] http://stackoverflow.com/questions/3402735/what-is-simplest-...

[cm2187]

I am not familiar enough with java which I assumed was a match for .net. But one line of code in .net.

IO.File.ReadAllText(FilePath)

[zbjornson]

Yeah, .net is way nicer than java and your argument holds pretty well in that case.

[fauigerzigerk]

What's wrong with

  new String(Files.readAllBytes(path));

or

  new String(Files.readAllBytes(path), StandardCharsets.UTF_8);

?

[vivin]

That's a very good point. The standard library for JavaScript is embarrassing to say the least. But you can't really fault it given the environment for which it was created. Node went some way towards making it a little better at least for the server side.