GoogleNetworkSpeechSynthesis VS assemblyscript

If you want you can use Google's TTS service without Web Speech API with a proxy, see GoogleNetworkSpeechSynthesis. I made a feature request for Google to release the source code as FOSS Re: Issue 263510047: Release TTS and STT source code and Google voices as FOSS so we don't have to make external requests just to use Web Speech API.

I requested to Google to Release TTS and STT source code and Google voices as FOSS which you can request over the network here GoogleNetworkSpeechSynthesis. Those are the voices Google Chrome uses for Web Speech API. Feel free to chime on the feature request in in support of Google releasing the source code of its network-based cloud service (that google uses for Web Speech API implementation) TTS and SST code as FOSS.

Technically you can use Google API key shipped in the browser see guest271314/ GoogleNetworkSpeechSynthesis . No need to sign up for a Google account to use this. I don't think Google's TTS is related to "AI".

This is how you can make the request yourself GoogleNetworkSpeechSynthesis.

If anybody want to build a TTS "module" or "component" that accepts and processes SSML input, and that the user can control - to an appreciable degree - on the front-end you can play around with this https://github.com/guest271314/GoogleNetworkSpeechSynthesis. (Makes an external request). Have fun!

It is possible to use Google Network Speech Synthesis service "free of charge", see GoogleNetworkSpeechSynthesis. On Chrome if you use Google voices with SpeechSynthesisUtterance() and window.speechSynthesis.speak() you are doing that anyway.

I implemented SSML parsing in JavaScript by hand for Web Speech API per SSML specification https://github.com/guest271314/SSMLParser, where the Web Speech API nor Firefox nor Chrome or Chromium browsers (Google does implement SSML parsing as a service https://github.com/guest271314/GoogleNetworkSpeechSynthesis) have implemented SSML parsing.

FYI when Google voices are used on Chrome or Chromium-based browsers the browser also makes a remote request, see https://github.com/guest271314/GoogleNetworkSpeechSynthesis.

How is processing SSML an attack vector? Google provides that capability as a service - with embedded limitations on character input that are not specified. This can and should be implemented in the browser - without making an external request; native-messaging-espeak-ng, GoogleNetworkSpeechSynthesis.

I like your take but JavaScript was literally the assembly language of the web until WASM came along. There was no other language that TypeScript could compile to.

This train of thought lead me to discover AssemblyScript! https://www.assemblyscript.org/

Incidentally, it’s also what AssemblyScript uses: https://github.com/AssemblyScript/assemblyscript/blob/main/s...

Use it as a Front-End for other low-level languages.

> MHO typescript could just cut loose from its javascript compatibility. Why not compile it to wasm instead of transpiling it to javascript?

Check out AssemblyScript which is exactly that:

https://www.assemblyscript.org/

If you're curious, check out AssemblyScript, that might describe better what needs to be cut from TypeScript to make it possible to be compiled to WASM.

This is kinda the idea behind AssemblyScript, but IIRC it's more of a low-level typescript-ish syntax for WebAssembly.

https://www.assemblyscript.org/ maybe, but I'm not sure exactly what you need.

Exactly, WASM was designed to be very very lightweight... you can put a lot of logic into a very small amount of WASM, but you need a good compiler to do that, or write WASM by hand to really feel the benefit. If you just compile Go to WASM, with its GC, runtime and stdlib included in the binary, yeah it's going to be pretty heavy... Rust doesn't have a runtime but as you said, for some reason, produces relatively large binaries (not the case only in WASM by the way). Probably, the best ways to create small WASM binaries is to compile from C or from a WASM-native language like AssemblySCript (https://www.assemblyscript.org).

Well we have all the new ECMA standards that will be introduced in 5 years now. It's looking more like Java actually. its accessor and typing patterns match it the most. TypeScript has had quite the profound influence over future ECMA design. There is a not so well known project called AssemblyScript which I think has a promising future. Since future ecma standards closely resembles it and TypeScripts popularity has exploded I have a feeling it may become a real standard as well.