rivescript-js
rivescript-js copied to clipboard
aichaos
Port to ES2015
This is sort of a long term maybe-nice-to-have goal for the JS implementation of RiveScript: rewrite the source code in EcmaScript 2015 (ES6).
There's this gist about migrating from CoffeeScript to ES6 which contains a nice overview of the new ES6 syntax and how it compares to CoffeeScript syntax.
A script like decaffeinate may help, if it produces high enough quality code. Otherwise a manual rewrite would produce better code.
There's also this article Don't Replace CoffeeScript with ES6 Transpilers, but most of its points are mostly only true of web browsers. Node supports ES6 so developers of Node apps could use the RiveScript-ES6 modules directly (no grunt build step needed to transpile from CS to JS), which also brings the benefit of Node devs being able to git clone this repo and use it immediately. But I'd have to investigate whether or not to support older versions of Node (if they can't just npm install it and get the raw ES6 code to work, that may be a reason not to move away from grunt to transpile code into ES5 syntax and therefore we can just stay on CoffeeScript).
For web browsers, there's already the required CoffeeScript+browserify steps to create a JS file suitable for the web, so replacing it with Babel isn't much different.
Very good idea, what do you think about implementing async functions from ES7 tho? I think that by the time new implementation is fully tested async functions will be supported by node.
you could also use Typescript to get typechecking and async/await is there right now. It will compile down to ES5 for browsers (tho not if you use await/async). I'm using that for current projects. If the goal is to keep things as simple as possible for more contributors, probably not a good idea, but if you want to have more powerful tooling but with a bit of setup overhead, then it's a good option IMHO.
There's also livescript which has a nice pipe syntax |> (like Elixir) that maybe good for these type of scripts where you're piping inputs around... but fairly niche tool.
Chiming in with my 2 cents: ES6 would be great, and Node's support is pretty incredible now. Most users won't have to transpile anymore, as I guess most users run rivescript-js on the server (do you have a hunch on that by the way?) to build their own custom APIs.
Typescript (basically just ES6/7 with type annotations) would make even more sense. Stronger type indications would go a long way in making the code more self-documented and understandable (and ultimately, making the project bigger and more active). The ecosystem is thriving right now and Typescript 2.0 is just around the corner. And type annotations might make their way into ES8 in any case!
Oh and by the way @kirsle I would also drop the support for browsers and focus on being Node only 😇
I think browser support is pretty important to maintain. It's one of the 'best' features I think of the JavaScript version.
If I was going to target Node only, then I wouldn't even need RiveScript to be written in JS at all, since Node could easily shell out and communicate with another program via process pipes (and the Perl and Python versions both have built-in JSON shells to be used for exactly that purpose), or if RiveScript was written in something C-compatible (like Go, or obviously C/C++) a Node addon could bind it that way.
Supporting the browser can also include a certain niche of developers that otherwise wouldn't have any other options. Think a customer support bot that can be run entirely from a user's browser, which could be served from a basic shared hosting account and has a much lower barrier of entry. For users of other engines (AIML, ChatScript, SuperScript), they'd have to, at the very least, learn some kind of server-side scripting language like PHP and find a hosting provider that allows that, or go with the even steeper learning curve and get a VPS and deal with server administration themselves.
sure it lowers the barrier to entry, but do you have any idea who is using it now? is anyone actually doing bots in the browser?
I would guess a lot of the more serious users (betaworks etc) are all about hooking up to messaging platforms - FBM, slack etc. That's where all the crazy hubbub is in the chatbot space... limiting to something just in the browser may cut off features you could otherwise do?
If rivescript was something that was written in another language entirely tho that would make me a bit nervous - like the source code wasn't there to be modified if need be. even tho it maybe there in another language/repo etc.
It's hard to quantify who's using the browser version of RiveScript for what.
I'm using it, though: the Try Online page and the RiveScript Playground both rely on it. I like offloading that stuff to the browser because it drastically simplifies all of the edge cases and pitfalls that I'd have to worry about if I did the processing on the server side. RiveScript is a very complicated library and I wouldn't be surprised to find out it has some vulnerabilities when told to load random untrusted inputs from people on the Internet. For example if somebody found a way to trap the library in an infinite loop or recursion condition, it could DoS the web server or something if it was the server side that did the processing.
Before I wrote the JS version I had a "Try Online" page written in Perl, and already I had to take a lot of steps and precautions to try to minimize the risk of the server being messed with by malicious users (e.g.: I disabled Perl object macro support, obviously, so people couldn't execute arbitrary Perl code, but I also took measures like running in a try/catch block with a timeout that would kill RiveScript if it takes longer than a couple seconds to do something, to try to nip any possible runaway loop errors in the bud).
By offloading the processing to the web browser I don't have to fret as much to secure my server from bad actors (the worst that would happen is a user DoS's their own web browser). The Playground site still complicates things with the "save snippets" feature, where a vulnerability could lead to a kind of "stored XSS" attack... but that's still an end user's problem and doesn't put the stability of the web server in jeopardy.
fair enough. it's also nice having the playground client side, as any errors in JS macros come up right away and it's easier to debug.
Don't forget about WebPack, it will help a lot people that uses WebPack, if you managed to full convert, I can write a .rive loader for WebPack.
