10 ms·

Javascript doesn't need and shouldn't have a "Standard Library". Javascript isn't python or c. It's more like Lua: It's meant to be embedded inside an applicati

Javascript doesn't need and shouldn't have a "Standard Library". Javascript isn't python or c. It's more like Lua: It's meant to be embedded inside an application, and the application provides all the interfaces you need. If you start trying to include things like file i/o in the base language, you're never going to satisfy all the very different requirements of code running in a browser vs. running on a server. If file I/O had been standardised years ago, with API designed by server programmers the browser would be saddled with lousy synchronous stuff that hangs the browser UI, opens up a thousand security issues, and bloats the language with stuff that's pointless for purposes that aren't web browsers or servers. If you think the web platform lacks something what you do is take it up with the W3C or WhatWG who are in charge of deciding what APIs the application exposes. if you want node to match the browser or vice versa, write a library. Finally the biggest and best reason to not do this is that, once you put something in javascript (or a web browser for that matter), you can never ever take it out no matter how badly designed it is, without breaking something. At least with an external library abstraction you can switch to a better designed library. Javascript and the web is an open platform. not a closed platform. The web browser itself provides a MASSIVE standard library that includes everything from a UI and text layout engine, to a standard graphics drawing library, a standard file io library, and plenty of other stuff you'd have to build from scratch in python or ruby. Don't undersell that.

BinaryIdiot 10y ago
> Javascript isn't python or c. It's more like Lua: It's meant to be embedded inside an application, and the application provides all the interfaces you need. I couldn't disagree more. JavaScript started out that way but today (really the past 6+ years) it's used in identical use cases as Python in addition to being embedded into web browsers. > If you start trying to include things like file i/o in the base language, you're never going to satisfy all the very different requirements of code running in a browser vs. running on a server. You don't need to. Provide the basic capabilities that all languages provide, restrict what isn't possible when it's embedded into an environment. Keep it simple. > If file I/O had been standardised years ago, with API designed by server programmers the browser would be saddled with lousy synchronous stuff that hangs the browser UI, opens up a thousand security issues, and bloats the language with stuff that's pointless for purposes that aren't web browsers or servers. This is very unfair. What's "years ago"? The asynchronous patterns used in JavaScript date back to well over a decade ago and JavaScript wasn't really used elsewhere until node.js. I'm not sure I would consider any standard APIs as "bloat" either. This just looks like a baseless attack. > Finally the biggest and best reason to not do this is that, once you put something in javascript (or a web browser for that matter), you can never ever take it out no matter how badly designed it is, without breaking something. Same goes for all programming languages and their standard libraries. This is why you target specific versions. This is a solved problem. > Javascript and the web is an open platform. not a closed platform. So is Python. C++. C#. etc.
- oceanswave 10y ago
  You're confusing a language with a platform. The language specs of the languages you mentioned do not have file system semantics included
  - BinaryIdiot 10y ago
    I'm not confusing anything here. Unless a language has a platform specific API it typically gets bundled into the language specifications itself to ensure consistent interfaces and to force implementations to match a set standard. C++'s STL is part of its specification. Python has a library reference outlining the interfaces their standard libraries must include. You're still thinking in browser world. In a browser world a browser is a platform and has to provide APIs to allow JavaScript to interact with its elements. Today this isn't always true. Today you have node.js and several other execution engines that allow JavaScript to run anywhere much like other languages. It's time the standard reflects that new reality, in my opinion.
    - deleted 10y ago
      [deleted]
- patates 10y ago
  > You don't need to. Provide the basic capabilities that all languages provide, restrict what isn't possible when it's embedded into an environment. Keep it simple. Well, that makes sense but wouldn't it make more sense that the environments supply what's meaningful on top of a very light base? Like window.document.querySelectorAll in browser and require("fs") in node.js? I, although, also think that stuff like what underscore/lodash provides could very well be in that light base, before we start discussing a standard for observables.
  - BinaryIdiot 10y ago
    > wouldn't it make more sense that the environments supply what's meaningful on top of a very light base I certainly don't think so. JavaScript is a language that works in more places now; commonized libraries would be a huge benefit. As an example you wouldn't use Python with different io libraries depending on the operating system it's running on and yet this is what node is evolving into. > Like window.document.querySelectorAll in browser and require("fs") in node.js? querySelector / querySelectorAll are specific to a browser platform but a way to conduct io could be pretty universal, in my opinion.
elliotec 10y ago
JavaScript doesn't just run in the web browser anymore. A standard library seems like an odd and annoying oversight at this point. Relevant blog post from Thomas Fuchs: https://medium.com/@thomasfuchs/what-if-we-had-a-great-standard-library-in-javascript-52692342ee3f#.aeuuv29bd https://medium.com/@thomasfuchs/what-if-we-had-a-great-stand...
rkwz 10y ago
(Please don't downvote parent if you disagree with parent's opinion, downvote only if it doesn't contribute to the discussion) @ZenPsycho: A standard library doesn't always have to mean file io or sockets etc. It could be better String/Array/Object manipulation apis, better utility functions (kinda like what underscore/loadsh provide) etc These are universal helpers that are very much needed whether you're writing code that runs in browser/server/mobile/iot etc. > If file I/O had been standardised years ago, with API designed by server programmers the browser would be saddled with lousy synchronous stuff that hangs the browser UI Maybe a bad example, but wouldn't sync file io be a problem in server as well?
- Kiro 10y ago
  > Please don't downvote parent if you disagree with parent's opinion, downvote only if it doesn't contribute to the discussion You are wrong. It's absolutely fine to downvote on disagreement. See the following comment from pg himself: http://news.ycombinator.com/item?id=117171 http://news.ycombinator.com/item?id=117171
  - tragic 10y ago
    It's also fine not to, which means (in my view) it's fine to ask others not to, if you disagree with pg and think it's unhelpful.
  - deleted 10y ago
    [deleted]
  - LionessLover 10y ago
    Which is wrong. As is the use of "absolutely" - to show that you have the universe-opinion. What hubris. And it does not matter that some guy "himself" posted some opinion either. Right were you link to there are different opinions from other people that show more thought was put into them. The "pg" comment actually is the only one for your argument, all others are against!
    - jholman 10y ago

BinaryIdiot 10y ago

> Javascript isn't python or c. It's more like Lua: It's meant to be embedded inside an application, and the application provides all the interfaces you need. I couldn't disagree more. JavaScript started out that way but today (really the past 6+ years) it's used in identical use cases as Python in addition to being embedded into web browsers. > If you start trying to include things like file i/o in the base language, you're never going to satisfy all the very different requirements of code running in a browser vs. running on a server. You don't need to. Provide the basic capabilities that all languages provide, restrict what isn't possible when it's embedded into an environment. Keep it simple. > If file I/O had been standardised years ago, with API designed by server programmers the browser would be saddled with lousy synchronous stuff that hangs the browser UI, opens up a thousand security issues, and bloats the language with stuff that's pointless for purposes that aren't web browsers or servers. This is very unfair. What's "years ago"? The asynchronous patterns used in JavaScript date back to well over a decade ago and JavaScript wasn't really used elsewhere until node.js. I'm not sure I would consider any standard APIs as "bloat" either. This just looks like a baseless attack. > Finally the biggest and best reason to not do this is that, once you put something in javascript (or a web browser for that matter), you can never ever take it out no matter how badly designed it is, without breaking something. Same goes for all programming languages and their standard libraries. This is why you target specific versions. This is a solved problem. > Javascript and the web is an open platform. not a closed platform. So is Python. C++. C#. etc.

oceanswave 10y ago
You're confusing a language with a platform. The language specs of the languages you mentioned do not have file system semantics included
- BinaryIdiot 10y ago
  I'm not confusing anything here. Unless a language has a platform specific API it typically gets bundled into the language specifications itself to ensure consistent interfaces and to force implementations to match a set standard. C++'s STL is part of its specification. Python has a library reference outlining the interfaces their standard libraries must include. You're still thinking in browser world. In a browser world a browser is a platform and has to provide APIs to allow JavaScript to interact with its elements. Today this isn't always true. Today you have node.js and several other execution engines that allow JavaScript to run anywhere much like other languages. It's time the standard reflects that new reality, in my opinion.
  - deleted 10y ago
    [deleted]
patates 10y ago
> You don't need to. Provide the basic capabilities that all languages provide, restrict what isn't possible when it's embedded into an environment. Keep it simple. Well, that makes sense but wouldn't it make more sense that the environments supply what's meaningful on top of a very light base? Like window.document.querySelectorAll in browser and require("fs") in node.js? I, although, also think that stuff like what underscore/lodash provides could very well be in that light base, before we start discussing a standard for observables.
- BinaryIdiot 10y ago
  > wouldn't it make more sense that the environments supply what's meaningful on top of a very light base I certainly don't think so. JavaScript is a language that works in more places now; commonized libraries would be a huge benefit. As an example you wouldn't use Python with different io libraries depending on the operating system it's running on and yet this is what node is evolving into. > Like window.document.querySelectorAll in browser and require("fs") in node.js? querySelector / querySelectorAll are specific to a browser platform but a way to conduct io could be pretty universal, in my opinion.

elliotec 10y ago

JavaScript doesn't just run in the web browser anymore. A standard library seems like an odd and annoying oversight at this point. Relevant blog post from Thomas Fuchs: https://medium.com/@thomasfuchs/what-if-we-had-a-great-standard-library-in-javascript-52692342ee3f#.aeuuv29bd https://medium.com/@thomasfuchs/what-if-we-had-a-great-stand...

rkwz 10y ago

(Please don't downvote parent if you disagree with parent's opinion, downvote only if it doesn't contribute to the discussion) @ZenPsycho: A standard library doesn't always have to mean file io or sockets etc. It could be better String/Array/Object manipulation apis, better utility functions (kinda like what underscore/loadsh provide) etc These are universal helpers that are very much needed whether you're writing code that runs in browser/server/mobile/iot etc. > If file I/O had been standardised years ago, with API designed by server programmers the browser would be saddled with lousy synchronous stuff that hangs the browser UI Maybe a bad example, but wouldn't sync file io be a problem in server as well?

Kiro 10y ago
> Please don't downvote parent if you disagree with parent's opinion, downvote only if it doesn't contribute to the discussion You are wrong. It's absolutely fine to downvote on disagreement. See the following comment from pg himself: http://news.ycombinator.com/item?id=117171 http://news.ycombinator.com/item?id=117171
- tragic 10y ago
  It's also fine not to, which means (in my view) it's fine to ask others not to, if you disagree with pg and think it's unhelpful.
- deleted 10y ago
  [deleted]
- LionessLover 10y ago
  Which is wrong. As is the use of "absolutely" - to show that you have the universe-opinion. What hubris. And it does not matter that some guy "himself" posted some opinion either. Right were you link to there are different opinions from other people that show more thought was put into them. The "pg" comment actually is the only one for your argument, all others are against!
  - jholman 10y ago