16 ms·

We're finally getting back to this point where you can choose whatever language you want to program for the web. It only took us 15 years of being flamed every

We're finally getting back to this point where you can choose whatever language you want to program for the web. It only took us 15 years of being flamed every time you pointed out you didn't like Javascript but were forced to use it to be part of the modern web. One of the motivations for Viaweb was being able to do Lisp, hopefully this gets the web back to that mindset of only the behavior mattering and whatever language you want to use go for it.

devwastaken 6y ago
It took 15 years for llvm and wasm to be made. Sandboxing and cross compilation in a way that isn't crazy has always been a big problem for allowing the web to just run whatever it wants. Though I'm still skeptical on wasms real security given its use in browsers is independently implimented, non seperable from the Js stack, and we're still using JIT. Everyone else goes and impliments their own runtime too.
- ChrisSD 6y ago
  Independent implementations are important. We don't want another Flash.
  - pjmlp 6y ago
    "Everything Old is New Again: Binary Security of WebAssembly" http://www.software-lab.org/publications/usenixSec2020-WebAssembly.pdf http://www.software-lab.org/publications/usenixSec2020-WebAs...
- amelius 6y ago
  We could as well have used VirtualBox instead to sandbox applications on the web, and run them at near-native speed. No need for LLVM and WASM. The only thing needed would be to incorporate VirtualBox into the browser.
  - derefr 6y ago
    Besides VirtualBox being an single implementation rather than a standard, that wouldn't have worked—VirtualBox is just a hypervisor, not an emulator, and so "has" whatever ISA the host has. So you'd need separate binaries for x86, ARM, etc. Google did a much better version of this, without these problems; they called it PNaCl. People still didn't like it, because LLVM IR is still not technically a formal standard, only a de-facto one.
    - amelius 6y ago
      > So you'd need separate binaries for x86, ARM, etc. I don't see this as a fundamental limitation. Perhaps I should have said QEMU instead of VirtualBox.
      - derefr 6y ago
        Google first developed NaCl, and that was rejected because of this problem. The main driver, I think, was that you can't predict the computing landscape. Just because we have certain common architectures around right now, doesn't mean there won't be new architectures around 20 years from now, and/or doesn't mean the architectures around now won't be dead by then. The thing about the web, and web standards, is that web clients (browsers) are expected to be able to work with web apps, on a common "web platform." Users expect to be able to take an up-to-date web browser and point it at any arbitrary old website, and have it work. And web platform engineers agree that this is how things should be, and make sure that browsers do everything they need to do to make this possible. But having the possibility of a web app delivering one of N different binaries for each of a bevy of random ISAs—and no requirement to support all ISAs, only whichever ones the site's author felt like deploying—means that the browser authors of 20-years-from-now, to support users' expectations of arbitrary old web apps "just working", would need to ship N virtual-machine interpreters, one for each ISA that people ever compiled web binaries for. Basically, it'd be a not-quite-combinatorial explosion in VM/runtime implementation work, which would decrease the quality that any one VM/runtime could have (which is really bad when those very implementations are one of the main sources of security vulnerabilities for attacking computers today.) And, even then, there'd still always be sites broken because they shipped native code only for a platform nobody ever bothered to build support into browsers for; or used an instruction only available on some extension of an ISA that only appears in some particular proprietary chipset. The web-standards people all agreed that, if you were going to have "object code for the web", it was much better to constrain the web to one "abstract machine" ISA. All the browser authors could then put all their effort behind implementing just one high-quality runtime/VM serving that abstract machine. The only dispute, after that, was what form the ISA would take. Google suggested LLVM IR, and was shot down. WASM came up with their own proposal, and it got accepted, probably mostly because it was a proposal for a standalone formal standard, rather than a de-facto part of something else. Probably, any ISA that was standalone in a similar way could have been used instead of WASM. But that is a surprisingly rare quality in an ISA. (For example, neither JVM nor CLR bytecode is a standard independent of the platform/runtime it's a part of. You can't become a member of the "JVM ISA steering committee", only a member of the Java working group.)
alsdkfjkqjwer 6y ago
...and to reset the score, yet again, on usability/accessibility. sigh.
untog 6y ago
> It only took us 15 years of being flamed every time you pointed out you didn't like Javascript I don't think that has ever been an unreasonable reaction. Nor is it all that unique: if you want to do iOS development in something other than Objective C or Swift then the iOS dev community is going to tell you that you're making a mistake. And they're often right. I've used Rust. I like Rust a lot. But one thing I don't see mentioned in this article at all: "debugger". Or "inspector". The web development stack has some incredible tools to aid in development, debug code, memory usage, etc. etc. Can you still use them with this single page app? If not, what strength is Rust bringing here that you can't achieve with the standard web dev stack?
- vlovich123 6y ago
  1. You can integrate existing high-quality libraries more natively 2. You can write your backend and front end in the same language which can be appealing to increase the ability for more people in the org to contribute code (eg you don’t need to hire a traditional web developer). 3. Tooling in rust is different. I’m sure the state of debugging and inspecting WASM will get better (I don’t actually know the state) but you’re now not limited to the tooling just in the browser and you can run all of that offline in a server 4. Performance 5. Tooling isn't there yet but it's an area of active development. Debugging in Chrome: https://developers.google.com/web/updates/2019/12/webassembly https://developers.google.com/web/updates/2019/12/webassembl...
  - untog 6y ago
    > you’re now not limited to the tooling just in the browser and you can run all of that offline in a server When it comes to DOM interaction (a key part of this article) you absolutely can’t. I see the logic in compiling a native library to Rust and using it via WASM. It’s the part where you bring the whole DOM WASM-side that I’m sceptical about. As you say, tooling isn’t there yet. Is performance even there yet? Last I heard WASM<->DOM interaction incurs a performance penalty. Right now it all feels like a “because I can” capability. I’m not saying that will always be the case, but for right here and now I’m sceptical.
root_axis 6y ago
It's ironic because this is only possible due to the continued development of sophisticated web tooling, which is the biggest complaint made by people who complain about the state of web development.
- learc83 6y ago
  People complaining about that are generally talking about the churn in front end web frameworks and JavaScript development in general. None of that eas necessary for WebAssembly to be developed. Unless you mean that the annoyance of the constantly changing JS ecosystem motivated people to push for it.
  - root_axis 6y ago
    Nobody wants to hand-write wasm, you need a tooling pipeline to make that type of development workflow practical, its not any different from babel or typescript in this respect; using rust instead of js is "churn" just as much as any of the other options available for building web pages that you don't have to use.
    - learc83 6y ago
      >Nobody wants to hand-write wasm, you need a tooling pipeline to make that type of development workflow practical, Yes and nothing about the Babel or typescript or node was required for the creation of wasm or a wasm compiler. People complain about churn in the JS ecosystem because of the rate that frameworks and tooling rise and then fall out of favor. I don't see the irony at all in people complaining about one ecosystem while being excited that they are being given a way to bypass that ecosystem all together.
      - root_axis 6y ago
        > People complain about churn in the JS ecosystem because of the rate that frameworks and tooling rise and then fall out of favor. And building web pages with rust is just another example of this phenomenon, its ironic because somehow its viewed as a positive thing by people who commonly complain about the introduction of new tools into web development ecosystem, but the power of rust hype somehow obscures the fact that this is exactly the same thing such detractors always complain about. For the record, I love rust and wasm and think this is great, but I have always been opposed to the framing that people creating new web development tools is a bad thing.
k__ 6y ago
"took us 15 years of being flamed every time you pointed out you didn't like Javascript" Rust is a special case here, light weight, and loved by JS devs. I'd still "flame" anyone who wants to drop a C# or Java VM on their users.
- pansa2 6y ago
  > Rust is [...] loved by JS devs. Is it? That's interesting, because to me the two languages seem to be polar opposites.
  - runawaybottle 6y ago
    You know what’s even more interesting? Using a low level language for no obvious performance reasons in the browser (as in, what performance critical thing are you solving?). I just remember having to do a lot of my college classes in C++, where some of our basic programs needed variables to be constantly cast into another type just to do something with it. I remember, man, I cannot wait to have to deal with this when I parse json data from an api request, bring it on. I am JS developer, and apparently I love Rust.
    - steveklabnik 6y ago
      Just because that was your C++ college experience, does not mean that reflects the experience of C++ today, let alone Rust today.
      - runawaybottle 6y ago
        Look, that web app in that tutorial is roughly 200-300 lines of code in regular js/css/html, maybe less. The onus is on you guys to tell me why I’d add cognitive overhead for simple webapps, and if it’s coming from the Rust community, I’m expecting to hear ‘performance’, in which case I’m game. I have the same opinion on overheard in the JS churn cycle, it’s up to you to make the case why the overhead makes sense for the cruddiest of apps. We shouldn’t coronate things willy nilly. If Rust is the one true blood prince of the C era, I expect him to reign in similar domains, but please don’t flex that power in domains where you are a sub standard solution. All hail Rust, but jesus, slow down. That’s a simple js app.
monadic2 6y ago
I mean, don't do this for other reasons, like it's an accessibility nightmare.
- riquito 6y ago
  You are getting downvoted because the rendered page is HTML, which has the same accessibility properties as always
  - monadic2 6y ago
    There's more to rendering than looking at the DOM at static points in time. There's certainly more to accessibility that conveying changes to the dom which may or may not be "visible", or certainly relevant, to the end user.
- samcgraw 6y ago
  Other than 10% of the globe unable to run wasm, what accessibility concerns come to mind here? Are there any that wouldn't also apply to a SPA that uses JS to manage the DOM?
  - steveklabnik 6y ago
    Some people believe that wasm will encourage people to turn web pages into one big <canvas>, which would be quite a hit. I don't personally believe that, though.
    - Shared404 6y ago
      I had in fact considered playing with and possibly deploying something like this if I liked it. I'd like to thank this thread for reminding me why that's probably not a good idea. Are there any good resources to read up on for making sure accessibility is good in <canvas>? I assume you'd have to implement it yourself.
      - steveklabnik 6y ago
dom96 6y ago
Are we? There are and have been plenty of languages that target JavaScript for many years now. What does webasm actually enable that wasn't possible before?
- gameswithgo 6y ago
  As per usual in the world of languages, nothing new is possible, but things can be easier and perform better.
- camgunz 6y ago
  This is what WebAssembly has to say about it: https://webassembly.org/docs/faq/ https://webassembly.org/docs/faq/
- flohofwoe 6y ago
  Performance (asm.js was pretty close but required special support from the JS engine too). But maybe more importantly: WASM frees Javascript from the future burden of being both a human-friendly programming language, and a machine-friendly compilation target.
  - pjmlp 6y ago
    Plugins already made that performance possible.
  - fulafel 6y ago
    Performance for a few low-level languages yes (Rust, C/C++), but with the GC support stalled and even less developed language interop story, there isn't anything in the horizon that promises to make it a good platform for today's HLL's. Meanwhile there are many nice HLL's targeting JSVM with good performance. I think the human friendliness transition happened already when most JS programmers started compiling their JS-version-du-jour to legacy-JS.
arkanciscan 6y ago
When you figure out that you still have to use the DOM and CSS you're gonna turn right back around like grandpa Simpson.
- runawaybottle 6y ago
  That and ui/ux programming. Gotta make sure you are displaying the right stuff, and be meticulous about your UI events/interactions. JavaScript might suck, but it’s got all the normal basic shit other languages have. Loops and shit, variables and stuff. You guys aren’t complaining about a little old language, you’re complaining about UI development and how tedious it can actually be if you want a professional level of polish.
- gameswithgo 6y ago
  don't have to, can use webgl.
  - untog 6y ago
    Bye bye, accessibility!
loxs 6y ago
Funny thing is, this is not strictly needed anymore, as TypeScript is probably the best language in existence right now. edit: OK, maybe not compared to Rust... but here it wins by ease of learning.
tyingq 6y ago
I suspect it won't really hit until the changes that enable direct DOM access, and things that make dynamic languages easier to implement in WASM. These things: https://github.com/WebAssembly/proposals/issues/16 https://github.com/WebAssembly/proposals/issues/16
- throwaway234101 6y ago
  Is that still happening? It looks like it's been on the back burner for a few years now.
sushshshsh 6y ago
It's the year 2020 and I'm still out here writing JSP, PL/SQL, and VB6 lmfao
- jaywalk 6y ago
  Please tell me this is a joke.
  - est31 6y ago
    There are two phases of a technology: the adoption for new projects phase, and the legacy phase. In the first phase, new projects dominate the programming activity in the technology. In the second phase, maintenance and improvement of already existing codebases dominates the activity. Technologies like jsp are in that second phase.
  - sushshshsh 6y ago
    Wish it was! My life is full of Dim iX As Integer and CURSOR AS right now and it's pretty gross. But it's better than writing css or react at least.
    - cdelsolar 6y ago
      um no it's not
      - AndrewUnmuted 6y ago
        Can't we agree that they're both just awful?
  - laurentdc 6y ago
    I know of at least two insurance companies in my country that still have their administrative software written in VB6 (probably along with some shoddy web app for IE8). Also see "IT runs on Java 8" https://veekaybee.github.io/2019/05/10/java8/ https://veekaybee.github.io/2019/05/10/java8/
- 6y ago
gedy 6y ago
It's funny because non web folks complain about Javascript fatigue and no standard libraries/approaches - so now on top of that we are going to mix in other languages and everyone bikeshedding the same thing in N languages? Seems maintaining apps with all this code is going to get a lot harder.
- pas 6y ago
  There is/was Scala.js too, and other similar things that "transpile" to JS.
Thaxll 6y ago
"where you can choose whatever language you want to program for the web" if by chosing meaning doing PoC during the week-end maybe ... for real work we don't have a choice.

devwastaken 6y ago

It took 15 years for llvm and wasm to be made. Sandboxing and cross compilation in a way that isn't crazy has always been a big problem for allowing the web to just run whatever it wants. Though I'm still skeptical on wasms real security given its use in browsers is independently implimented, non seperable from the Js stack, and we're still using JIT. Everyone else goes and impliments their own runtime too.

ChrisSD 6y ago
Independent implementations are important. We don't want another Flash.
- pjmlp 6y ago
  "Everything Old is New Again: Binary Security of WebAssembly" http://www.software-lab.org/publications/usenixSec2020-WebAssembly.pdf http://www.software-lab.org/publications/usenixSec2020-WebAs...
amelius 6y ago
We could as well have used VirtualBox instead to sandbox applications on the web, and run them at near-native speed. No need for LLVM and WASM. The only thing needed would be to incorporate VirtualBox into the browser.
- derefr 6y ago
  Besides VirtualBox being an single implementation rather than a standard, that wouldn't have worked—VirtualBox is just a hypervisor, not an emulator, and so "has" whatever ISA the host has. So you'd need separate binaries for x86, ARM, etc. Google did a much better version of this, without these problems; they called it PNaCl. People still didn't like it, because LLVM IR is still not technically a formal standard, only a de-facto one.
  - amelius 6y ago
    > So you'd need separate binaries for x86, ARM, etc. I don't see this as a fundamental limitation. Perhaps I should have said QEMU instead of VirtualBox.
    - derefr 6y ago
      Google first developed NaCl, and that was rejected because of this problem. The main driver, I think, was that you can't predict the computing landscape. Just because we have certain common architectures around right now, doesn't mean there won't be new architectures around 20 years from now, and/or doesn't mean the architectures around now won't be dead by then. The thing about the web, and web standards, is that web clients (browsers) are expected to be able to work with web apps, on a common "web platform." Users expect to be able to take an up-to-date web browser and point it at any arbitrary old website, and have it work. And web platform engineers agree that this is how things should be, and make sure that browsers do everything they need to do to make this possible. But having the possibility of a web app delivering one of N different binaries for each of a bevy of random ISAs—and no requirement to support all ISAs, only whichever ones the site's author felt like deploying—means that the browser authors of 20-years-from-now, to support users' expectations of arbitrary old web apps "just working", would need to ship N virtual-machine interpreters, one for each ISA that people ever compiled web binaries for. Basically, it'd be a not-quite-combinatorial explosion in VM/runtime implementation work, which would decrease the quality that any one VM/runtime could have (which is really bad when those very implementations are one of the main sources of security vulnerabilities for attacking computers today.) And, even then, there'd still always be sites broken because they shipped native code only for a platform nobody ever bothered to build support into browsers for; or used an instruction only available on some extension of an ISA that only appears in some particular proprietary chipset. The web-standards people all agreed that, if you were going to have "object code for the web", it was much better to constrain the web to one "abstract machine" ISA. All the browser authors could then put all their effort behind implementing just one high-quality runtime/VM serving that abstract machine. The only dispute, after that, was what form the ISA would take. Google suggested LLVM IR, and was shot down. WASM came up with their own proposal, and it got accepted, probably mostly because it was a proposal for a standalone formal standard, rather than a de-facto part of something else. Probably, any ISA that was standalone in a similar way could have been used instead of WASM. But that is a surprisingly rare quality in an ISA. (For example, neither JVM nor CLR bytecode is a standard independent of the platform/runtime it's a part of. You can't become a member of the "JVM ISA steering committee", only a member of the Java working group.)

alsdkfjkqjwer 6y ago

...and to reset the score, yet again, on usability/accessibility. sigh.

untog 6y ago

> It only took us 15 years of being flamed every time you pointed out you didn't like Javascript I don't think that has ever been an unreasonable reaction. Nor is it all that unique: if you want to do iOS development in something other than Objective C or Swift then the iOS dev community is going to tell you that you're making a mistake. And they're often right. I've used Rust. I like Rust a lot. But one thing I don't see mentioned in this article at all: "debugger". Or "inspector". The web development stack has some incredible tools to aid in development, debug code, memory usage, etc. etc. Can you still use them with this single page app? If not, what strength is Rust bringing here that you can't achieve with the standard web dev stack?

vlovich123 6y ago
1. You can integrate existing high-quality libraries more natively 2. You can write your backend and front end in the same language which can be appealing to increase the ability for more people in the org to contribute code (eg you don’t need to hire a traditional web developer). 3. Tooling in rust is different. I’m sure the state of debugging and inspecting WASM will get better (I don’t actually know the state) but you’re now not limited to the tooling just in the browser and you can run all of that offline in a server 4. Performance 5. Tooling isn't there yet but it's an area of active development. Debugging in Chrome: https://developers.google.com/web/updates/2019/12/webassembly https://developers.google.com/web/updates/2019/12/webassembl...
- untog 6y ago
  > you’re now not limited to the tooling just in the browser and you can run all of that offline in a server When it comes to DOM interaction (a key part of this article) you absolutely can’t. I see the logic in compiling a native library to Rust and using it via WASM. It’s the part where you bring the whole DOM WASM-side that I’m sceptical about. As you say, tooling isn’t there yet. Is performance even there yet? Last I heard WASM<->DOM interaction incurs a performance penalty. Right now it all feels like a “because I can” capability. I’m not saying that will always be the case, but for right here and now I’m sceptical.

root_axis 6y ago

It's ironic because this is only possible due to the continued development of sophisticated web tooling, which is the biggest complaint made by people who complain about the state of web development.

learc83 6y ago
People complaining about that are generally talking about the churn in front end web frameworks and JavaScript development in general. None of that eas necessary for WebAssembly to be developed. Unless you mean that the annoyance of the constantly changing JS ecosystem motivated people to push for it.
- root_axis 6y ago
  Nobody wants to hand-write wasm, you need a tooling pipeline to make that type of development workflow practical, its not any different from babel or typescript in this respect; using rust instead of js is "churn" just as much as any of the other options available for building web pages that you don't have to use.
  - learc83 6y ago
    >Nobody wants to hand-write wasm, you need a tooling pipeline to make that type of development workflow practical, Yes and nothing about the Babel or typescript or node was required for the creation of wasm or a wasm compiler. People complain about churn in the JS ecosystem because of the rate that frameworks and tooling rise and then fall out of favor. I don't see the irony at all in people complaining about one ecosystem while being excited that they are being given a way to bypass that ecosystem all together.
    - root_axis 6y ago
      > People complain about churn in the JS ecosystem because of the rate that frameworks and tooling rise and then fall out of favor. And building web pages with rust is just another example of this phenomenon, its ironic because somehow its viewed as a positive thing by people who commonly complain about the introduction of new tools into web development ecosystem, but the power of rust hype somehow obscures the fact that this is exactly the same thing such detractors always complain about. For the record, I love rust and wasm and think this is great, but I have always been opposed to the framing that people creating new web development tools is a bad thing.

k__ 6y ago

"took us 15 years of being flamed every time you pointed out you didn't like Javascript" Rust is a special case here, light weight, and loved by JS devs. I'd still "flame" anyone who wants to drop a C# or Java VM on their users.

pansa2 6y ago
> Rust is [...] loved by JS devs. Is it? That's interesting, because to me the two languages seem to be polar opposites.
- runawaybottle 6y ago
  You know what’s even more interesting? Using a low level language for no obvious performance reasons in the browser (as in, what performance critical thing are you solving?). I just remember having to do a lot of my college classes in C++, where some of our basic programs needed variables to be constantly cast into another type just to do something with it. I remember, man, I cannot wait to have to deal with this when I parse json data from an api request, bring it on. I am JS developer, and apparently I love Rust.
  - steveklabnik 6y ago
    Just because that was your C++ college experience, does not mean that reflects the experience of C++ today, let alone Rust today.
    - runawaybottle 6y ago
      Look, that web app in that tutorial is roughly 200-300 lines of code in regular js/css/html, maybe less. The onus is on you guys to tell me why I’d add cognitive overhead for simple webapps, and if it’s coming from the Rust community, I’m expecting to hear ‘performance’, in which case I’m game. I have the same opinion on overheard in the JS churn cycle, it’s up to you to make the case why the overhead makes sense for the cruddiest of apps. We shouldn’t coronate things willy nilly. If Rust is the one true blood prince of the C era, I expect him to reign in similar domains, but please don’t flex that power in domains where you are a sub standard solution. All hail Rust, but jesus, slow down. That’s a simple js app.

monadic2 6y ago

I mean, don't do this for other reasons, like it's an accessibility nightmare.

riquito 6y ago
You are getting downvoted because the rendered page is HTML, which has the same accessibility properties as always
- monadic2 6y ago
  There's more to rendering than looking at the DOM at static points in time. There's certainly more to accessibility that conveying changes to the dom which may or may not be "visible", or certainly relevant, to the end user.
samcgraw 6y ago
Other than 10% of the globe unable to run wasm, what accessibility concerns come to mind here? Are there any that wouldn't also apply to a SPA that uses JS to manage the DOM?
- steveklabnik 6y ago
  Some people believe that wasm will encourage people to turn web pages into one big <canvas>, which would be quite a hit. I don't personally believe that, though.
  - Shared404 6y ago
    I had in fact considered playing with and possibly deploying something like this if I liked it. I'd like to thank this thread for reminding me why that's probably not a good idea. Are there any good resources to read up on for making sure accessibility is good in <canvas>? I assume you'd have to implement it yourself.
    - steveklabnik 6y ago

dom96 6y ago

Are we? There are and have been plenty of languages that target JavaScript for many years now. What does webasm actually enable that wasn't possible before?

gameswithgo 6y ago
As per usual in the world of languages, nothing new is possible, but things can be easier and perform better.
camgunz 6y ago
This is what WebAssembly has to say about it: https://webassembly.org/docs/faq/ https://webassembly.org/docs/faq/
flohofwoe 6y ago
Performance (asm.js was pretty close but required special support from the JS engine too). But maybe more importantly: WASM frees Javascript from the future burden of being both a human-friendly programming language, and a machine-friendly compilation target.
- pjmlp 6y ago
  Plugins already made that performance possible.
- fulafel 6y ago
  Performance for a few low-level languages yes (Rust, C/C++), but with the GC support stalled and even less developed language interop story, there isn't anything in the horizon that promises to make it a good platform for today's HLL's. Meanwhile there are many nice HLL's targeting JSVM with good performance. I think the human friendliness transition happened already when most JS programmers started compiling their JS-version-du-jour to legacy-JS.

arkanciscan 6y ago

When you figure out that you still have to use the DOM and CSS you're gonna turn right back around like grandpa Simpson.

runawaybottle 6y ago
That and ui/ux programming. Gotta make sure you are displaying the right stuff, and be meticulous about your UI events/interactions. JavaScript might suck, but it’s got all the normal basic shit other languages have. Loops and shit, variables and stuff. You guys aren’t complaining about a little old language, you’re complaining about UI development and how tedious it can actually be if you want a professional level of polish.
gameswithgo 6y ago
don't have to, can use webgl.
- untog 6y ago
  Bye bye, accessibility!

loxs 6y ago

Funny thing is, this is not strictly needed anymore, as TypeScript is probably the best language in existence right now. edit: OK, maybe not compared to Rust... but here it wins by ease of learning.

tyingq 6y ago

I suspect it won't really hit until the changes that enable direct DOM access, and things that make dynamic languages easier to implement in WASM. These things: https://github.com/WebAssembly/proposals/issues/16 https://github.com/WebAssembly/proposals/issues/16

throwaway234101 6y ago
Is that still happening? It looks like it's been on the back burner for a few years now.

sushshshsh 6y ago

It's the year 2020 and I'm still out here writing JSP, PL/SQL, and VB6 lmfao

jaywalk 6y ago
Please tell me this is a joke.
- est31 6y ago
  There are two phases of a technology: the adoption for new projects phase, and the legacy phase. In the first phase, new projects dominate the programming activity in the technology. In the second phase, maintenance and improvement of already existing codebases dominates the activity. Technologies like jsp are in that second phase.
- sushshshsh 6y ago
  Wish it was! My life is full of Dim iX As Integer and CURSOR AS right now and it's pretty gross. But it's better than writing css or react at least.
  - cdelsolar 6y ago
    um no it's not
    - AndrewUnmuted 6y ago
      Can't we agree that they're both just awful?
- laurentdc 6y ago
  I know of at least two insurance companies in my country that still have their administrative software written in VB6 (probably along with some shoddy web app for IE8). Also see "IT runs on Java 8" https://veekaybee.github.io/2019/05/10/java8/ https://veekaybee.github.io/2019/05/10/java8/
6y ago

gedy 6y ago

It's funny because non web folks complain about Javascript fatigue and no standard libraries/approaches - so now on top of that we are going to mix in other languages and everyone bikeshedding the same thing in N languages? Seems maintaining apps with all this code is going to get a lot harder.

pas 6y ago
There is/was Scala.js too, and other similar things that "transpile" to JS.

Thaxll 6y ago

"where you can choose whatever language you want to program for the web" if by chosing meaning doing PoC during the week-end maybe ... for real work we don't have a choice.