JavaScript Studio publicly available | Hacker News Reader

JavaScript Studio publicly available

medium.com

63 pointsingve30 comments

> This made clear that offering the tool as a cloud service is an issue in corporate environments. To mitigate this, the CLI now encrypts all source code on your machine, the service decrypts it only in memory to run the analyzer and then all sources are immediately deleted.

That wouldn't cover any of the corporate policies I've seen. It's a total no go for companies under government regulation like HIPAA.

Company lawyers will block devs from using your service. IMHO, you have to provide an enterprise version of your platform that can run on in house servers.

If none of the data is visible server side why is this a service in the first place? Everything is a bunch of js running in-browser.

Just sell it like JetBrains. Sure home users will pirate it but with IDE's the money is made with companies and enterprise versions anyways.

Agreed completely. A similar situation occurs with things like ransomware which technically count as a data breach since they requirement is loss of control of the underlying data (despite no data actually be transmitted out of the network).

Aka "we are using SSL and not persisting the code to disk once we have it". Not all that reassuring, other than maybe protecting them from someone stealing a hard drive...

This will satisfy tons of corporate reviews.

Businesses put code on Github and Bitbucket all the time.

And why are you putting HIPAA information in your code?!?

HIPAA isn't only about personal health information. Your application can never run on shared servers at any time.

(1) That's not true.

(2) Even if it were true, it would only pertain to running your application with PHI.

This is a development environment, not a production one. There should be no HIPPA issues developing and testing your code in public. If there is, then you're doing it wrong.

Your point about corporate policies is right on the mark though. Not many corporations are going to want their code sent to a 3rd party in any form, encrypted or otherwise.

Yeah that's not true. See AWS's HIPAA certified services for one example.

I would change the tagline to "Finding runtime errors at compile time" instead of "The ground-breaking new way to find runtime errors".

JS isn't typically compiled, obviously, but if you're using "compile time" as a synonym for static analysis, then it looks like that's not what this does. He specifically describes it as being dynamic, not static, analysis.

Pardon my ignorance but why is this valuable? Why wouldn't I just run the javascript in a browser/node process and check for runtime errors? Isn't it a natural part of development to write code -> run in browser/node to see if it works?

I was wondering the same thing. It sounds like an interesting technology, but I would have liked to have seen a lot more demos of it in action.

> The analyzer will parse your source code into an AST. It will then evaluate the AST dynamically, trying to reach every possible execution branch. If a global entry point is specified, every exposed function will be evaluated, including functions that are returned by other functions. [0]

For anything but the smallest of libraries, testing every path through the code would be pretty burdensome to do in the browser on every change. Of course you can do it with the right test plan, but it doesn't take long for a codebase to get large enough to make it difficult to reason about the entire AST. At the very least, it seems like this is a good tool for exposing the blind spots in your testing. :)

[0] https://javascript.studio/features/

Ah cool, I didn't notice that. And I must admit, I am not familiar with how an AST works. My application makes a lot of HTTP requests and is full of async operations. How would it handle this? It wouldn't be able to run most of the code because all of the data is missing...

It does the job an expert human can do by reading the code without executing it.

function willFail() {

  let x = null


  console.log(x.method())


 }

You can read that this function will throw an exception all the time. But you may never execute this function in your test cases, so you won't see this problem in development but only too late, when a user hits the problem in prod.

It is called a static analysis and is 99.9% of the time faster to perform than executing every possible cases of your code. It doesn't catch exactly the same kind of issues either; so both are complementary.

Unfortunately it also thinks every function that uses a native browser variable/object (e.g. `screen` in my case) means it will fail because I never defined `screen` in my code.

Other analysis tools like JSHint allow you to specify certain globals ($) or that you are in a browser environment with special annotations to handle this situation. I couldn't find anything in their documentation like that.

The documentation has a list of supported browser features: https://javascript.studio/docs/browser-features

Ideally all the browser APIs should be supported by the tool without the need to manually declare any globals.

Just so I understand, this is a closed-source, cloud-hosted subset of the features of the closure compiler?

https://developers.google.com/closure/compiler/

(Edit: never mind, it looks like the closure compiler can also be used as a service by posting your javascript to at http://closure-compiler.appspot.com/compile)

To my knowledge closure compiler only supports partial code execution through heavy code annotation; e.g. lots of doc bloc comments. This seems like a different approach that doesn't need that.

After using Jetbrains products for work, I wouldn't think twice about paying for a personal license, if it means they keep making such an incredible product line. I wonder if most feel the same.

I think this looks super interesting. Great job shipping. I too would like to see more examples of the errors that it can catch in the documentation.

Ignore the troll posts, they happen every time a hacker posts news about a project they've launched on Hacker News.

New examples have been added to the "Features" pages: https://javascript.studio/features/runtime-errors

It seems that, according to your survey, you managed to not account for 32.1% of your potential users for upload (there's no way that your TLS+privacy policy will pass legal in a company that cares). Then not account for 80.4% of your users, by building it for the wrong ES version and requiring babel compilation. Then not account for any of the node users (granted, max of 1.8% use node exclusively). This appears to be quite excellent market research, but it seems to have resulted in the wrong product?

What is online now is the basic requirement for all of the potential users. ES 6 will follow, Node will follow, and hopefully an On-Premises solution will follow too. The research helped find the right place to start and where to go from there. I can't do everything at once :)

I love this post as a description of how a Product Manager can act on customer metrics that are misaligned with your own intuition.

How does that compare to writing tests and checking code coverage?

The docs says that it tries to explore all the branches of the AST, isn't that what coverage is doing?

I might be missing something.

JS Studio does it for you. Best to think of it along the lines of a fuzzer for JS.

A brief scroll through makes this sound like a JS-specific version of Sentry, is that correct?

Sentry relies on instrumentation and custom logic. It requires code branches to be executed either by users or some form of automated tests. JavaScript Studio doesn't need code adjustments and can execute multiple code branches without knowing all the parameters up front.

Reply on news.ycombinator.com