7 ms·

Bash is much older than JavaScript. If it was going to turn into a real programming language, it would have by now. It hasn't. Also, JavaScript really is not a

by hsn915 5y ago

Bash is much older than JavaScript. If it was going to turn into a real programming language, it would have by now. It hasn't. Also, JavaScript really is not a very good programming language. We are just stuck with it because it's the only language the browser understands. (Well, until recently: things are going to change with the introduction of wasm). But for the shell, we're not stuck with any one language. Whatever you want to do can be programmed in your favorite language. You can easily write a python script instead of a bash function.

raziel2p 5y ago
> things are going to change with the introduction of wasm people have been saying this for years already and nothing seems to have come of it :(
- tambourine_man 5y ago
  Yeah. Turns out, having an interpreted runtime in the browser is quite useful and sending bytecode across the wire not as practical. We've been forgetting and relearning that for the past two decades.
  - hsn915 5y ago
    "turns out"? How did it turn out so? Actually it turns out that having an interpreted runtime causes a stream of endless problem. We keep try to patch them over but new problems keep coming up. It turns out that a standarized low level byte code is the right way to ship cross platform applications. We already knew that. It just took a long time to go through the standarization process and be implemented by browsers. If it seems like it's not in use today, it's largely because JavaScript has momentum and the majority of web programmers don't yet know how to take advantage of wasm (or maybe don't think they need it).
    - tambourine_man 5y ago
      > It turns out that a standarized low level byte code is the right way to ship cross platform applications So why hasn’t it taken over the world with Java and now with wasm? > If it seems like it's not in use today, it's largely because JavaScript has momentum and the majority of web programmers don't yet know how to take advantage of wasm (or maybe don't think they need it). There’s another possible reason. I’m sure you can come up with the answer yourself.
      - hsn915 5y ago
        Javascript never really had a chance to "take over the world" before Google released Chrome and the V8 engine. Before that it was just too slow. Java applets really sucked. They took a long time to load and initialize. They all looked ugly (probably because of the default libraries?). Also Java itself as a language was really bad and the development experience was awful. I want to say that no one wants to program in Java but in reality many people do (I don't understand those people). The important lesson here is the implementation is more important than the idea. Good idea with bad implementation -> goes no where. wasm is not java. The important quality about wasm is that it's not garbage collected. It's pretty close to just good old assembly.
        tambourine_man 5y ago
        >Javascript never really had a chance to "take over the world" before Google released Chrome and the V8 engine. Chrome was released at the end of 2008, JavaScript was thriving way before that. We had Gmail since 2004, jQuery since 2006. WebApps were the “sweet solution” considered for iPhone apps at first in 2007. Chrome exists because of the healthy ecosystem that Firefox and Safari provided, not the other way around. >It's pretty close to just good old assembly. Precisely, and it's yet to be proven that's the best solution for the Web. I love it from the computer science perpective, but historically that idea hasn't struck a chord.
- steve_adams_86 5y ago
  Is that true though? Aren’t people using it for in-browser image and video editing? Doesn’t Google use it for drawing to Sheets and crunching numbers? I thought that was the case but I can’t recall where I read it. If that’s not true then I should probably reconsider my thinking about wasm
  - heavyset_go 5y ago
    Yes, WASM is a good target for CPU bound number crunching. I'm not sure if it's used in Sheets, though.
- heavyset_go 5y ago
  I've seen some pretty interesting things like the use of Rust for front end development, like yew[1] and Seed[2]. There aren't many languages that are practical for WASM output. Scripting and managed languages need to ship their interpreters and runtimes with their WASM blobs, and can end up relatively large. JavaScript's interpreter and runtime are baked into every browser already. That leaves only compiled and unmanaged languages for potentially good WASM targets. As mentioned before, Rust is seeing a lot development in that space. If LLVM can compile it, then Emscripten can output it to WASM. [1] https://github.com/yewstack/yew https://github.com/yewstack/yew [2] https://github.com/seed-rs/seed https://github.com/seed-rs/seed
- hsn915 5y ago
  Are you sure nothing came of it? Figma for example seems to be largely powered by WASM and the core of the product seems to be written in C++ https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/ https://www.figma.com/blog/webassembly-cut-figmas-load-time-... https://www.figma.com/blog/building-a-professional-design-tool-on-the-web/ https://www.figma.com/blog/building-a-professional-design-to... I think the majority of web developers are just slow at catching up with this new things.
- copperx 5y ago
  WASM DOM manipulation will probably come soon, and that will place other languages in the exact same playing field as Javascript. For now, manipulating the DOM still requires calling Javascript.
- twox2 5y ago
  Wasm isn't really going to change the front-end / browser side of javascript for the better, but it's great for graphics and anything else cpu intensive.
addicted 5y ago
What’s wrong with modern JavaScript as a programming language (although I would maybe point to typescript which adds types to JS instead)?
- seba_dos1 5y ago
  There's no distinct "modern JavaScript", it's still the same language. It just has bunch of things added to make it more manageable, but it still contains all the footguns and gotchas as it did before. Its tooling got significantly better in the last decade or so, but you still need to intentionally rely on it in order to work with the language in any sensible way. You can't really hope for any other outcome when maintaining backwards compatibility.
  - hsn915 5y ago
    The tooling only got better last year with esbuild. Everything else is either unmanageably complicated (webpack) or slow (rollup, parcel, babel). React mainstreamed the idea of using a virtualdom to accelerate UI building (accelerate in the computational sense: by not dealing directly with the slow DOM).
    - seba_dos1 5y ago
      I remember how webdev looked like 15 years ago. The tooling did get better even before esbuild - but I never said it was "good" :)
- hsn915 5y ago
  I responded to the sibling comment asking the same question https://news.ycombinator.com/item?id=29068066 https://news.ycombinator.com/item?id=29068066
dotancohen 5y ago
> JavaScript really is not a very good programming language. Since 2015, JavaScript really is a nice language. I never thought that I'd say that. Go look at ES6 (the javascript version that came out in 2015) and even TypeScript. You'll be pleasantly surprised, no matter if you're coming from C++, Java, C# or even other "scripting" languages such as PHP and Python.
- hsn915 5y ago
  I use typescript almost daily. It's certainly better than Python or Ruby, I'll grant you that. But I don't think Python is a good language either. Ultimately I want a langauge with value types like structs and arrays that you can use to do computations without allocating things on the heap. In Go I can write a function that returns two numbers. In Javascript I can only return two numbers by allocating an array on the heap with two items. These two items themselves are probably pointers to two number objects allocated separately. So that's 5 allocations to return two numbers. It's insane. This means fundamentally it's impossible to create applications in javascript that are both sophisticated and high performance. A great example to illustrate this is the tooling around Javascript itself. There were all kinds of bundlers: webpack, rollup, parcel, etc. Rollup was considered the fastest and lightest. They were all programmed in Javascript itself. They were all slow. But no one really knew how bad it was because there was nothing really better. Then esbuild comes along, and blows all of them completely out of the water, out performing them by 100 times. And it's written in Go. A language that supports structs and arrays as value types.
  - gfodor 5y ago
    It’s not fundamentally impossible to build fast apps in JS. It’s just not possible to do if you don’t do the legwork of writing code that the compiler will optimize for you. It’s not easy, and it’s not natural in a lot of cases, but saying it is fundamentally impossible goes too far: people build high performance applications like games in JS. For example, you are worried about value types but under the hood the JIT compiler will actually generate efficient representations that are passed by value if you do not mess things up for it. Modern JS compilers are extremely sophisticated. For returning values without an allocation, you’d create such a “struct” and then use a memory pool. It would still be heap allocated I believe but not totally sure. People who know more than I do could probably tell you a better method to return multiple values from a function efficiently.

by hsn915 5y ago

raziel2p 5y ago

> things are going to change with the introduction of wasm people have been saying this for years already and nothing seems to have come of it :(

tambourine_man 5y ago
Yeah. Turns out, having an interpreted runtime in the browser is quite useful and sending bytecode across the wire not as practical. We've been forgetting and relearning that for the past two decades.
- hsn915 5y ago
  "turns out"? How did it turn out so? Actually it turns out that having an interpreted runtime causes a stream of endless problem. We keep try to patch them over but new problems keep coming up. It turns out that a standarized low level byte code is the right way to ship cross platform applications. We already knew that. It just took a long time to go through the standarization process and be implemented by browsers. If it seems like it's not in use today, it's largely because JavaScript has momentum and the majority of web programmers don't yet know how to take advantage of wasm (or maybe don't think they need it).
  - tambourine_man 5y ago
    > It turns out that a standarized low level byte code is the right way to ship cross platform applications So why hasn’t it taken over the world with Java and now with wasm? > If it seems like it's not in use today, it's largely because JavaScript has momentum and the majority of web programmers don't yet know how to take advantage of wasm (or maybe don't think they need it). There’s another possible reason. I’m sure you can come up with the answer yourself.
    - hsn915 5y ago
      Javascript never really had a chance to "take over the world" before Google released Chrome and the V8 engine. Before that it was just too slow. Java applets really sucked. They took a long time to load and initialize. They all looked ugly (probably because of the default libraries?). Also Java itself as a language was really bad and the development experience was awful. I want to say that no one wants to program in Java but in reality many people do (I don't understand those people). The important lesson here is the implementation is more important than the idea. Good idea with bad implementation -> goes no where. wasm is not java. The important quality about wasm is that it's not garbage collected. It's pretty close to just good old assembly.
      - tambourine_man 5y ago
        >Javascript never really had a chance to "take over the world" before Google released Chrome and the V8 engine. Chrome was released at the end of 2008, JavaScript was thriving way before that. We had Gmail since 2004, jQuery since 2006. WebApps were the “sweet solution” considered for iPhone apps at first in 2007. Chrome exists because of the healthy ecosystem that Firefox and Safari provided, not the other way around. >It's pretty close to just good old assembly. Precisely, and it's yet to be proven that's the best solution for the Web. I love it from the computer science perpective, but historically that idea hasn't struck a chord.
steve_adams_86 5y ago
Is that true though? Aren’t people using it for in-browser image and video editing? Doesn’t Google use it for drawing to Sheets and crunching numbers? I thought that was the case but I can’t recall where I read it. If that’s not true then I should probably reconsider my thinking about wasm
- heavyset_go 5y ago
  Yes, WASM is a good target for CPU bound number crunching. I'm not sure if it's used in Sheets, though.
heavyset_go 5y ago
I've seen some pretty interesting things like the use of Rust for front end development, like yew[1] and Seed[2]. There aren't many languages that are practical for WASM output. Scripting and managed languages need to ship their interpreters and runtimes with their WASM blobs, and can end up relatively large. JavaScript's interpreter and runtime are baked into every browser already. That leaves only compiled and unmanaged languages for potentially good WASM targets. As mentioned before, Rust is seeing a lot development in that space. If LLVM can compile it, then Emscripten can output it to WASM. [1] https://github.com/yewstack/yew https://github.com/yewstack/yew [2] https://github.com/seed-rs/seed https://github.com/seed-rs/seed
hsn915 5y ago
Are you sure nothing came of it? Figma for example seems to be largely powered by WASM and the core of the product seems to be written in C++ https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/ https://www.figma.com/blog/webassembly-cut-figmas-load-time-... https://www.figma.com/blog/building-a-professional-design-tool-on-the-web/ https://www.figma.com/blog/building-a-professional-design-to... I think the majority of web developers are just slow at catching up with this new things.
copperx 5y ago
WASM DOM manipulation will probably come soon, and that will place other languages in the exact same playing field as Javascript. For now, manipulating the DOM still requires calling Javascript.
twox2 5y ago
Wasm isn't really going to change the front-end / browser side of javascript for the better, but it's great for graphics and anything else cpu intensive.

addicted 5y ago

What’s wrong with modern JavaScript as a programming language (although I would maybe point to typescript which adds types to JS instead)?

seba_dos1 5y ago
There's no distinct "modern JavaScript", it's still the same language. It just has bunch of things added to make it more manageable, but it still contains all the footguns and gotchas as it did before. Its tooling got significantly better in the last decade or so, but you still need to intentionally rely on it in order to work with the language in any sensible way. You can't really hope for any other outcome when maintaining backwards compatibility.
- hsn915 5y ago
  The tooling only got better last year with esbuild. Everything else is either unmanageably complicated (webpack) or slow (rollup, parcel, babel). React mainstreamed the idea of using a virtualdom to accelerate UI building (accelerate in the computational sense: by not dealing directly with the slow DOM).
  - seba_dos1 5y ago
    I remember how webdev looked like 15 years ago. The tooling did get better even before esbuild - but I never said it was "good" :)
hsn915 5y ago
I responded to the sibling comment asking the same question https://news.ycombinator.com/item?id=29068066 https://news.ycombinator.com/item?id=29068066

dotancohen 5y ago

> JavaScript really is not a very good programming language. Since 2015, JavaScript really is a nice language. I never thought that I'd say that. Go look at ES6 (the javascript version that came out in 2015) and even TypeScript. You'll be pleasantly surprised, no matter if you're coming from C++, Java, C# or even other "scripting" languages such as PHP and Python.

hsn915 5y ago
I use typescript almost daily. It's certainly better than Python or Ruby, I'll grant you that. But I don't think Python is a good language either. Ultimately I want a langauge with value types like structs and arrays that you can use to do computations without allocating things on the heap. In Go I can write a function that returns two numbers. In Javascript I can only return two numbers by allocating an array on the heap with two items. These two items themselves are probably pointers to two number objects allocated separately. So that's 5 allocations to return two numbers. It's insane. This means fundamentally it's impossible to create applications in javascript that are both sophisticated and high performance. A great example to illustrate this is the tooling around Javascript itself. There were all kinds of bundlers: webpack, rollup, parcel, etc. Rollup was considered the fastest and lightest. They were all programmed in Javascript itself. They were all slow. But no one really knew how bad it was because there was nothing really better. Then esbuild comes along, and blows all of them completely out of the water, out performing them by 100 times. And it's written in Go. A language that supports structs and arrays as value types.
- gfodor 5y ago
  It’s not fundamentally impossible to build fast apps in JS. It’s just not possible to do if you don’t do the legwork of writing code that the compiler will optimize for you. It’s not easy, and it’s not natural in a lot of cases, but saying it is fundamentally impossible goes too far: people build high performance applications like games in JS. For example, you are worried about value types but under the hood the JIT compiler will actually generate efficient representations that are passed by value if you do not mess things up for it. Modern JS compilers are extremely sophisticated. For returning values without an allocation, you’d create such a “struct” and then use a memory pool. It would still be heap allocated I believe but not totally sure. People who know more than I do could probably tell you a better method to return multiple values from a function efficiently.