[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.