4 ms·

Ladies and gentlemen we already have TypeScript, Dart, clojurescript, scalajs, coffeescript, PureScript, elm, etc. More innovation in the web language ecosystem

Ladies and gentlemen we already have TypeScript, Dart, clojurescript, scalajs, coffeescript, PureScript, elm, etc. More innovation in the web language ecosystem is not what is lacking. What is lacking is all the boring stuff like a sensible package management system, deployment mechanism, framework interoperability, etc. You know, all the un-sexy stuff that actual engineering requires.

alongub 12y ago
Note that Spider comes _from_ an actual engineering requirement. http://spiderlang.org/#why-spider http://spiderlang.org/#why-spider
- dkarapetyan 12y ago
  Please don't take my comment as dismissive of your work. I think it's really cool and the list of language features is quite impressive. I only disagree with the dynamic typing statement. Both TypeScript and AtScript are optionally/gradually typed which means your code can be as dynamically typed as you want it to be so you still retain the benefits of dynamic types. For some the backwards compatibility might be an issue but I personally like the fact that any JavaScript code is automatically valid TypeScript code that I can easily migrate to use more and more TypeScript features.
adam-a 12y ago
> Ladies and gentlemen we already have NPM, Bower, Component, Duo, Jam, etc. More package management systems are not what is lacking. What is lacking ... I find your comment to be snide, ungrateful and most of all uninformed. Personally I think new programming languages are interesting, despite how widely they might or might not end up being used, if they present new ideas, or solve difficult problems. Spider seems to solve a few Javascript problems and does so with a different approach to the other languages you listed.
- dkarapetyan 12y ago
  You forgot jspm.io. So are you enjoying having all those choices and each one being subtly incompatible with all the others? Let me know how your next spider project turns out and how it interoperates with all the existing code written in coffeescript, typescript, dart, vanilla js, etc.
mst 12y ago
Actually, this looks like it hits a sweet spot (for my taste at least) that none of the others really quite do. Ironically, I've now filed this in my head as something to look at when adding a web UI to some package management and deployment code I'm working on :)
fizzbatter 12y ago
I can't help but be confused by the point of your comment (not trying to sound mean). Are you saying that he (we?) shouldn't be developing new languages, and instead focus on "things that matter"? Ie, don't work on what you want to work on, work on what is useful to others / "solves real problems"? I mean, that statement, while very useful at heart, seems ultimately close minded to me. It chips away at the soul of trying something new, or doing something fun. I mean, i don't think anyone would argue that we need more languages, but i would (and am, apparently) argue against the idea that we shouldn't be creating new languages because we don't "need" them. Not everything should be industry scale and immediately applicable to professional needs.
- dkarapetyan 12y ago
  New for the sake of being new is not engineering, it's fashion. Programming fundamentally is a problem solving discipline which means the tools I adopt and use at the end of the day are about augmenting my ability to solve new and novel problems instead of spinning my wheels in place and re-writing yet another old library in the new language du jour. The JavaScript framework/application ecosystem could use less fashion and more engineering. That doesn't mean I don't think that spider is cool. In fact the list of language features is really well thought out.
NickPollard 12y ago
What we really need is a replacement for Javascript as the 'bytecode of the internet'. It's clear now that people want to have the freedom to write client web code in whatever language they prefer. A web browser is just a VM for running the output of a [dart, coffeescript, scala...] compiler, and we should recognise that, and replace javascript (a language designed for humans to write) with a new bytecode (a language designed for computers to run), and then people can use whatever compilers they want to translate from the code they write to the code the user runs. People can still write javascript with a JS->Bytecode compiler; people who want to write TypeScript or Dart can get better compilation or performance, and people can easily write a whole load of new languages and new compilers without being constrained by the intricacies and design decisions of Javascript.
- rtpg 12y ago
  I'll take "Subsets of Javascript by Mozilla" for $200, Alex I think asm.js has proven itself to be a "good enough" solution if we start writing some serious compiler tech
  - NickPollard 12y ago
    I didn't mention asm.js but it was on my mind when I wrote the parent; it's possible that it is 'good enough' and eventually becomes widely adopted enough, but I wonder if we might do better by eschewing the need for compatibility with Javascript.
    - deleted 12y ago
      [deleted]
    - bobajeff 12y ago
      We might but first someone has to first design and specify the new Intermediate Language. Then submit it to ECMA. Then implement it in a browser. This new IR better be so much better than JavaScript and asm.js at being a compile target for languages, that it takes no time for web application developers and compiler developers support it with enough tools and applications to dwarf their JavaScript counterparts. Good luck with that.
rtpg 12y ago
I disagree. There's still lacking a good compile-to-JS language that works well in the current library ecosystem (ruling out scalajs and fay) and has ADTs and good static typing.
- frowaway001 12y ago
  LOL. So basically "I want X, but languages which give me X are excluded, because that would hurt my claim"? Especially compared to Scala.js and Fay, I don't see the point of going backward to a slightly improved JavaScript again.
- dkarapetyan 12y ago
  You mean PureScript?
demarq 12y ago
Well you may want to read this link which may address your first complaint existing languages. http://spiderlang.org/#why-spider I think package management is well handled by npm on node and browserify on the browser. projects like grunt make deployment a piece of cake. framework interoperability is just like in any other language, it's up to individual library maintainers. Personally I've rarely had issues with interoperability. On the plus side I think on that same link you'll find that Spider works happily interops with vanilla js. One way we could look at it is this; all these languages mean there is an option for everyone. I think if you look at the list of langs you mentioned (throw in vanilla js as well) you will find one that really speaks to you.
Practicality 12y ago
I have to disagree on principle and yet agree. This looks a lot better than the other options and I really hope it catches on. However, I can't really use it until it catches on, because I need all this "other" stuff to be done before I can use it in my projects.

alongub 12y ago

Note that Spider comes _from_ an actual engineering requirement. http://spiderlang.org/#why-spider http://spiderlang.org/#why-spider

dkarapetyan 12y ago
Please don't take my comment as dismissive of your work. I think it's really cool and the list of language features is quite impressive. I only disagree with the dynamic typing statement. Both TypeScript and AtScript are optionally/gradually typed which means your code can be as dynamically typed as you want it to be so you still retain the benefits of dynamic types. For some the backwards compatibility might be an issue but I personally like the fact that any JavaScript code is automatically valid TypeScript code that I can easily migrate to use more and more TypeScript features.

adam-a 12y ago

> Ladies and gentlemen we already have NPM, Bower, Component, Duo, Jam, etc. More package management systems are not what is lacking. What is lacking ... I find your comment to be snide, ungrateful and most of all uninformed. Personally I think new programming languages are interesting, despite how widely they might or might not end up being used, if they present new ideas, or solve difficult problems. Spider seems to solve a few Javascript problems and does so with a different approach to the other languages you listed.

dkarapetyan 12y ago
You forgot jspm.io. So are you enjoying having all those choices and each one being subtly incompatible with all the others? Let me know how your next spider project turns out and how it interoperates with all the existing code written in coffeescript, typescript, dart, vanilla js, etc.

mst 12y ago

Actually, this looks like it hits a sweet spot (for my taste at least) that none of the others really quite do. Ironically, I've now filed this in my head as something to look at when adding a web UI to some package management and deployment code I'm working on :)

fizzbatter 12y ago

I can't help but be confused by the point of your comment (not trying to sound mean). Are you saying that he (we?) shouldn't be developing new languages, and instead focus on "things that matter"? Ie, don't work on what you want to work on, work on what is useful to others / "solves real problems"? I mean, that statement, while very useful at heart, seems ultimately close minded to me. It chips away at the soul of trying something new, or doing something fun. I mean, i don't think anyone would argue that we need more languages, but i would (and am, apparently) argue against the idea that we shouldn't be creating new languages because we don't "need" them. Not everything should be industry scale and immediately applicable to professional needs.

dkarapetyan 12y ago
New for the sake of being new is not engineering, it's fashion. Programming fundamentally is a problem solving discipline which means the tools I adopt and use at the end of the day are about augmenting my ability to solve new and novel problems instead of spinning my wheels in place and re-writing yet another old library in the new language du jour. The JavaScript framework/application ecosystem could use less fashion and more engineering. That doesn't mean I don't think that spider is cool. In fact the list of language features is really well thought out.

NickPollard 12y ago

What we really need is a replacement for Javascript as the 'bytecode of the internet'. It's clear now that people want to have the freedom to write client web code in whatever language they prefer. A web browser is just a VM for running the output of a [dart, coffeescript, scala...] compiler, and we should recognise that, and replace javascript (a language designed for humans to write) with a new bytecode (a language designed for computers to run), and then people can use whatever compilers they want to translate from the code they write to the code the user runs. People can still write javascript with a JS->Bytecode compiler; people who want to write TypeScript or Dart can get better compilation or performance, and people can easily write a whole load of new languages and new compilers without being constrained by the intricacies and design decisions of Javascript.

rtpg 12y ago
I'll take "Subsets of Javascript by Mozilla" for $200, Alex I think asm.js has proven itself to be a "good enough" solution if we start writing some serious compiler tech
- NickPollard 12y ago
  I didn't mention asm.js but it was on my mind when I wrote the parent; it's possible that it is 'good enough' and eventually becomes widely adopted enough, but I wonder if we might do better by eschewing the need for compatibility with Javascript.
  - deleted 12y ago
    [deleted]
  - bobajeff 12y ago
    We might but first someone has to first design and specify the new Intermediate Language. Then submit it to ECMA. Then implement it in a browser. This new IR better be so much better than JavaScript and asm.js at being a compile target for languages, that it takes no time for web application developers and compiler developers support it with enough tools and applications to dwarf their JavaScript counterparts. Good luck with that.

rtpg 12y ago

I disagree. There's still lacking a good compile-to-JS language that works well in the current library ecosystem (ruling out scalajs and fay) and has ADTs and good static typing.

frowaway001 12y ago
LOL. So basically "I want X, but languages which give me X are excluded, because that would hurt my claim"? Especially compared to Scala.js and Fay, I don't see the point of going backward to a slightly improved JavaScript again.
dkarapetyan 12y ago
You mean PureScript?

demarq 12y ago

Well you may want to read this link which may address your first complaint existing languages. http://spiderlang.org/#why-spider I think package management is well handled by npm on node and browserify on the browser. projects like grunt make deployment a piece of cake. framework interoperability is just like in any other language, it's up to individual library maintainers. Personally I've rarely had issues with interoperability. On the plus side I think on that same link you'll find that Spider works happily interops with vanilla js. One way we could look at it is this; all these languages mean there is an option for everyone. I think if you look at the list of langs you mentioned (throw in vanilla js as well) you will find one that really speaks to you.

Practicality 12y ago

I have to disagree on principle and yet agree. This looks a lot better than the other options and I really hope it catches on. However, I can't really use it until it catches on, because I need all this "other" stuff to be done before I can use it in my projects.