4 ms·

Flash and Java applets were a big thing, these ARE client side languages. But to work well the vendor had to install a runtime on your PC. Back in the day JavaS

Flash and Java applets were a big thing, these ARE client side languages. But to work well the vendor had to install a runtime on your PC. Back in the day JavaScript/HTML was too slow and inconsistent for intensive client side work. So people that wanted into intense client side apps used these runtimes. Cross platform support across many vendors has always been hard. Look at cross platform libraries in C. Different compilers, OS, and std library implementations. Python or Ruby on the other hand have one “vendor” that works to make the runtime consistent on different platforms. So for something like Python or Ruby to work well, it’d need to either be: 1. A central vendor driving development, who would need to manage and install a runtime on your computer Or 2. All browser vendors have to buy into a single spec and make a very consistent implementation across their browsers. Or 3. Compile to JavaScript (or web asm etc) For (2) browser vendors already invest heavily in JavaScript and have a hard time keeping up! For (1) I’m not sure why any language vendor cares to try to compete with JavaScript seriously. The browser is quite different environment than the CLI or Desktop that it’d be a significant investment without clear upside. We do see (3) with Typescript and Coffeescript. These create some debugging friction. Also as JavaScript gets marginally better the appeal of these other languages can feel more niche, and many people just use the common denominator.

dcminter 5y ago
All fair points, but still, don't you think it's a little surprising that browsers never supported perl client side? That seems like the obvious one to me given all the cgi scripting written in it.
- eqvinox 5y ago
  > surprising that browsers never supported perl client side? They did, actually: https://perlhelp.web.cern.ch/Components/Windows/PerlScript.html https://perlhelp.web.cern.ch/Components/Windows/PerlScript.h... If you installed ActivePerl, you could use, in IE 5.0, <script language=perlscript>…</script> I even remember using this for shits and giggles. And then I noticed noone else was willing to install it, and gave up on it. (Don't get confused by the server-side bits, those are for IIS, this stuff did both server-side and client-side...) [Ed.add.: also I don't think Netscape ever supported anything other than JavaScript, but I'm not sure of that.]
  - dcminter 5y ago
    Nice! I had no idea that existed!
  - jordemort 5y ago
    I actually used the server-side version of PerlScript to mix some code from CPAN into a classic ASP application, way back at the dawn of my career. It was pretty neat. I, too, had dreams of using the client-side version, but getting folks to install it was indeed much too tough of a sell.
brundolf 5y ago
> We do see (3) with Typescript and Coffeescript And ClojureScript, and PureScript, and Elm, etc Honestly, in my hobbyist experience, JavaScript is a joy to use as a compilation target. All the flexibility and the laundry list of features which can make it a handful to use directly, make it a wonderful base for nearly any kind of language you can imagine. And because it's higher-level, you can focus your energy on your own language instead of on re-implementing the fundamentals from scratch. And then of course it performs better than most similarly-flexible languages, and runs anywhere.
- goatlover 5y ago
  WebAssembly is a much better target for compiled languages. And JS runs anywhere in the same way that Java does, which is wherever someone has installed a virtual machine for it, which is usually a web browser or Node for JS. But it doesn't run on more places than C or C++, which can be compiled to run on almost any hardware in existence.
  - brundolf 5y ago
    > WebAssembly is a much better target for compiled languages Depends on what you're trying to do. My language projects are almost always higher-level and garbage-collected, so again, targeting WASM would mean re-implementing fundamentals from scratch all the time. I'm glad to focus instead on interesting language features, translating those to be in terms of JS features.
fallenspec 5y ago
> We do see (3) with Typescript and Coffeescript. These create some debugging friction. Also as JavaScript gets marginally better the appeal of these other languages can feel more niche, and many people just use the common denominator. I have no idea with Coffeescript (I've read about it, but never used it). But my current job is basically spent all day writing TypeScript. 1) There is no debugging friction. I can debug TypeScript directly in my browser. 2) It isn't marginally better over JavaScript. It is leaps and bounds better than JavaScript. TypeScript compiler will catch many, many, many common problems straight away (provided it is configured correctly). I have written a lot of JavaScript and I don't enjoy going back to having to write regular JavaScript.
- horsawlarway 5y ago
  The friction with typescript is the build environment (speaking as someone who also prefers it, and uses it all day). If someone else is handling that work for you (and in most companies this does essentially become a core responsibility for a few critical maintainers) then yes - Typescript feels great. If you have a small, single person project - there's enough real overhead there that I'm not sure typescript is the right initial choice.
  - fallenspec 5y ago
    > The friction with typescript is the build environment (speaking as someone who also prefers it, and uses it all day). You can literally do: tsc filename.ts And you will have a javascript file that you can run in a browser. No configuration files needed, just need to install the typescript compiler. Sure if you need more complicated things. You will need a more complicated setup. But it is no worse (and in someways better) than most of the ecosystem. > If someone else is handling that work for you (and in most companies this does essentially become a core responsibility for a few critical maintainers) then yes - Typescript feels great. I don't know where you work. However I've done this myself by myself. It is well documented and it isn't that difficult. I think the hardest to setup from scratch is webpack, but Gulp is fairly straightforward. I've have set stuff up completely from scratch and created my own framework with TypeScript (I was bored during lockdown) and it takes maybe a day to figure out with webpack. Not something for a beginner. However you don't need a whole team to do this or specific people looking after it. > If you have a small, single person project - there's enough real overhead there that I'm not sure typescript is the right initial choice. The same could be said of any other language where you need any sort of build system and a compiler.

dcminter 5y ago

All fair points, but still, don't you think it's a little surprising that browsers never supported perl client side? That seems like the obvious one to me given all the cgi scripting written in it.

eqvinox 5y ago
> surprising that browsers never supported perl client side? They did, actually: https://perlhelp.web.cern.ch/Components/Windows/PerlScript.html https://perlhelp.web.cern.ch/Components/Windows/PerlScript.h... If you installed ActivePerl, you could use, in IE 5.0, <script language=perlscript>…</script> I even remember using this for shits and giggles. And then I noticed noone else was willing to install it, and gave up on it. (Don't get confused by the server-side bits, those are for IIS, this stuff did both server-side and client-side...) [Ed.add.: also I don't think Netscape ever supported anything other than JavaScript, but I'm not sure of that.]
- dcminter 5y ago
  Nice! I had no idea that existed!
- jordemort 5y ago
  I actually used the server-side version of PerlScript to mix some code from CPAN into a classic ASP application, way back at the dawn of my career. It was pretty neat. I, too, had dreams of using the client-side version, but getting folks to install it was indeed much too tough of a sell.

brundolf 5y ago

> We do see (3) with Typescript and Coffeescript And ClojureScript, and PureScript, and Elm, etc Honestly, in my hobbyist experience, JavaScript is a joy to use as a compilation target. All the flexibility and the laundry list of features which can make it a handful to use directly, make it a wonderful base for nearly any kind of language you can imagine. And because it's higher-level, you can focus your energy on your own language instead of on re-implementing the fundamentals from scratch. And then of course it performs better than most similarly-flexible languages, and runs anywhere.

goatlover 5y ago
WebAssembly is a much better target for compiled languages. And JS runs anywhere in the same way that Java does, which is wherever someone has installed a virtual machine for it, which is usually a web browser or Node for JS. But it doesn't run on more places than C or C++, which can be compiled to run on almost any hardware in existence.
- brundolf 5y ago
  > WebAssembly is a much better target for compiled languages Depends on what you're trying to do. My language projects are almost always higher-level and garbage-collected, so again, targeting WASM would mean re-implementing fundamentals from scratch all the time. I'm glad to focus instead on interesting language features, translating those to be in terms of JS features.

fallenspec 5y ago

> We do see (3) with Typescript and Coffeescript. These create some debugging friction. Also as JavaScript gets marginally better the appeal of these other languages can feel more niche, and many people just use the common denominator. I have no idea with Coffeescript (I've read about it, but never used it). But my current job is basically spent all day writing TypeScript. 1) There is no debugging friction. I can debug TypeScript directly in my browser. 2) It isn't marginally better over JavaScript. It is leaps and bounds better than JavaScript. TypeScript compiler will catch many, many, many common problems straight away (provided it is configured correctly). I have written a lot of JavaScript and I don't enjoy going back to having to write regular JavaScript.

horsawlarway 5y ago
The friction with typescript is the build environment (speaking as someone who also prefers it, and uses it all day). If someone else is handling that work for you (and in most companies this does essentially become a core responsibility for a few critical maintainers) then yes - Typescript feels great. If you have a small, single person project - there's enough real overhead there that I'm not sure typescript is the right initial choice.
- fallenspec 5y ago
  > The friction with typescript is the build environment (speaking as someone who also prefers it, and uses it all day). You can literally do: tsc filename.ts And you will have a javascript file that you can run in a browser. No configuration files needed, just need to install the typescript compiler. Sure if you need more complicated things. You will need a more complicated setup. But it is no worse (and in someways better) than most of the ecosystem. > If someone else is handling that work for you (and in most companies this does essentially become a core responsibility for a few critical maintainers) then yes - Typescript feels great. I don't know where you work. However I've done this myself by myself. It is well documented and it isn't that difficult. I think the hardest to setup from scratch is webpack, but Gulp is fairly straightforward. I've have set stuff up completely from scratch and created my own framework with TypeScript (I was bored during lockdown) and it takes maybe a day to figure out with webpack. Not something for a beginner. However you don't need a whole team to do this or specific people looking after it. > If you have a small, single person project - there's enough real overhead there that I'm not sure typescript is the right initial choice. The same could be said of any other language where you need any sort of build system and a compiler.