4 ms·

Wouldn't it be funny if we see a resurgence of compile-to-js languages? If JavaScript keeps on piling up layers I could see people longing for a simpler, smalle

by svckr 9y ago

Wouldn't it be funny if we see a resurgence of compile-to-js languages? If JavaScript keeps on piling up layers I could see people longing for a simpler, smaller language. Where there was coffeescript to highlight functional features in JS in a time where most JS was imperative, maybe we'll see a language that takes the OO sugar away to, again, reveal the functional language that's underneath.

kodablah 9y ago
FWIW the arguably ideal target for compile-to-web tech, WebAssembly, is adding some OO too [0]. 0 - https://github.com/WebAssembly/gc/blob/master/proposals/gc/Overview.md#objects-and-method-tables https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...
- just_astounded 9y ago
  Until wasm has GC, we're not likely to see much in the way of compile-to-web outside of C, C++, or Rust.
  - pjmlp 9y ago
    There is already a .NET prototype. https://github.com/SteveSanderson/Blazor https://github.com/SteveSanderson/Blazor https://www.youtube.com/watch?v=MiLAE6HMr10 https://www.youtube.com/watch?v=MiLAE6HMr10 WebAssembly without native GC support is no different that targeting a real hardware CPU. One just has to implement it as well. As soon as WebAssembly reaches a more mature state, expect the resurgence of plugins and this time around we won't be able to disable them.
    - gulbanana 9y ago
      blazor is not .NET compiled to WASM. blazor uses a .NET runtime called DotNetAnywhere, which is written in C and compiled with emscripten. the actual .NET IL is then interpreted at runtime by DNA.
      - pjmlp 9y ago
        True, but the fact is that people are already toying with the idea of bring such runtimes back into the browser. Also if you bother to read the meeting minutes from WebAssembly meetings, developers from .NET team are present in such meetings.
    - just_astounded 9y ago
      Fancy!
erikpukinskis 9y ago
I am absolutely planning on forking an old school JavaScript off of the current runtimes. Or at least forking NPM. Not soon, because for now writing ES5 and running it on ES6 runtimes is Good Enough for my current purposes, as I'm still <1.0.0 so nothing really matters. But eventually I'm going to want a separate package space, and a separate language community. Modern JavaScript is cool, but it loses many of the benefits of old school JS: - only runs on newer devices - requires a precompile step - more language to learn - confusing concurrency model - confusing inheritance mechanisms - no incentive to learn to use closures, callbacks, and prototypes properly If I was willing to accept all of those things, I would just use a straight up better language, like Rust or Haskell, and get the additional benefits of type checking and deterministic performance. But I'm not interested in those things. I want a simple run-everywhere language for beginners to get started on. JavaScript used to be that, but modern JavaScript is not that language anymore. So, I'm going to bring back ES5. Why not. Who's with me?
- just_astounded 9y ago
  I remember when Crockford released the fantastic book, JavaScript The Good Parts. I disagreed with some of his opinions in that book, like avoiding the use of 'new', but that book - more than almost anything else, helped me educate folks on how to use js well. I used to order copies for every member of my team. I wonder if, instead of a fork, we can just make a case for a subset of js. Take the good new things, and ignore the rest, like a modern "Good Parts".
  - mercer 9y ago
    Could you elaborate on the things you disagreed with? For example, for some reason I prefer avoiding new but I'm conflicted about it. I'd really like to hear your input as to why perhaps using 'new' is a good thing.
    - erikpukinskis 9y ago
      Not OP, but new is dangerous because it makes it easy to put a lot of methods on an object, which is generally an anti-pattern. But sometimes that's what you want. I think a good use case is view models... You're not mutating anything, but you have a large number of consumers that are using different subsets of views on a piece of data. Constructing those by hand can be a PITA. Although, it's dangerous there. "Lots of views on a piece of data" might be a way of covering up "several disparate pieces of data in one place" or "data that is playing two roles when it should be transmuted instead". So, it's good to be afraid of new. I am still frequently decomposing a single index of objects into separate indexes of literals fairly often. I often get sucked into thinking something is an object when it's really just a few separate pieces of data indexed together. I also use new for libraries that export something that isn't exactly a function, but more a point of reference. For example my browser-bridge module is a point of reference for the computation between a web request and response. It's not really an action, but it's a thin representation over a handful of low level things you want to do in that space. It's purpose is to wrap up a set of concerns. Essentially, OO is generally bad in JavaScript, but sometimes it's good and in those cases new is nice.

by svckr 9y ago

kodablah 9y ago

FWIW the arguably ideal target for compile-to-web tech, WebAssembly, is adding some OO too [0]. 0 - https://github.com/WebAssembly/gc/blob/master/proposals/gc/Overview.md#objects-and-method-tables https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...

just_astounded 9y ago
Until wasm has GC, we're not likely to see much in the way of compile-to-web outside of C, C++, or Rust.
- pjmlp 9y ago
  There is already a .NET prototype. https://github.com/SteveSanderson/Blazor https://github.com/SteveSanderson/Blazor https://www.youtube.com/watch?v=MiLAE6HMr10 https://www.youtube.com/watch?v=MiLAE6HMr10 WebAssembly without native GC support is no different that targeting a real hardware CPU. One just has to implement it as well. As soon as WebAssembly reaches a more mature state, expect the resurgence of plugins and this time around we won't be able to disable them.
  - gulbanana 9y ago
    blazor is not .NET compiled to WASM. blazor uses a .NET runtime called DotNetAnywhere, which is written in C and compiled with emscripten. the actual .NET IL is then interpreted at runtime by DNA.
    - pjmlp 9y ago
      True, but the fact is that people are already toying with the idea of bring such runtimes back into the browser. Also if you bother to read the meeting minutes from WebAssembly meetings, developers from .NET team are present in such meetings.
  - just_astounded 9y ago
    Fancy!

erikpukinskis 9y ago

I am absolutely planning on forking an old school JavaScript off of the current runtimes. Or at least forking NPM. Not soon, because for now writing ES5 and running it on ES6 runtimes is Good Enough for my current purposes, as I'm still <1.0.0 so nothing really matters. But eventually I'm going to want a separate package space, and a separate language community. Modern JavaScript is cool, but it loses many of the benefits of old school JS: - only runs on newer devices - requires a precompile step - more language to learn - confusing concurrency model - confusing inheritance mechanisms - no incentive to learn to use closures, callbacks, and prototypes properly If I was willing to accept all of those things, I would just use a straight up better language, like Rust or Haskell, and get the additional benefits of type checking and deterministic performance. But I'm not interested in those things. I want a simple run-everywhere language for beginners to get started on. JavaScript used to be that, but modern JavaScript is not that language anymore. So, I'm going to bring back ES5. Why not. Who's with me?

just_astounded 9y ago
I remember when Crockford released the fantastic book, JavaScript The Good Parts. I disagreed with some of his opinions in that book, like avoiding the use of 'new', but that book - more than almost anything else, helped me educate folks on how to use js well. I used to order copies for every member of my team. I wonder if, instead of a fork, we can just make a case for a subset of js. Take the good new things, and ignore the rest, like a modern "Good Parts".
- mercer 9y ago
  Could you elaborate on the things you disagreed with? For example, for some reason I prefer avoiding new but I'm conflicted about it. I'd really like to hear your input as to why perhaps using 'new' is a good thing.
  - erikpukinskis 9y ago
    Not OP, but new is dangerous because it makes it easy to put a lot of methods on an object, which is generally an anti-pattern. But sometimes that's what you want. I think a good use case is view models... You're not mutating anything, but you have a large number of consumers that are using different subsets of views on a piece of data. Constructing those by hand can be a PITA. Although, it's dangerous there. "Lots of views on a piece of data" might be a way of covering up "several disparate pieces of data in one place" or "data that is playing two roles when it should be transmuted instead". So, it's good to be afraid of new. I am still frequently decomposing a single index of objects into separate indexes of literals fairly often. I often get sucked into thinking something is an object when it's really just a few separate pieces of data indexed together. I also use new for libraries that export something that isn't exactly a function, but more a point of reference. For example my browser-bridge module is a point of reference for the computation between a web request and response. It's not really an action, but it's a thin representation over a handful of low level things you want to do in that space. It's purpose is to wrap up a set of concerns. Essentially, OO is generally bad in JavaScript, but sometimes it's good and in those cases new is nice.