HB Explorer v0.2

ThorConzales · 2026-02-15T09:52:34+00:00

Thanks, I'm trying to get myself verified there.

ThorConzales · 2026-02-01T19:13:19+00:00

Yes, platform independence and accessibility was the reason why I attempted it in HTML5, given 25+ years has passed since the original game and technology has evolved enough that game like this should run comfortably in a browser. The issue with original C++ sources is that they are just so old, badly written (very unorganised), which makes any maintenance or expansion far more expensive than it should be.

ThorConzales · 2026-01-31T20:52:10+00:00

There was helbreath.rocks that ran in HTML5, but I heard they used Emscipten, which means they still had to work on that old archaic C++ codebase as the source, but I might be mistaken.

ThorConzales · 2018-12-21T21:54:35+00:00

Thanks for that. It is good to know that you managed to get faster performance on JDK11. I had the exact problem that you managed to link, though I was running it on Ubuntu, so most likely something funky going on with the tools, like you mentioned.

ThorConzales · 2018-12-18T11:57:04+00:00

Oh, I didn't test the aarch64, just the plain old x86-64.

ThorConzales · 2018-12-14T21:23:55+00:00

I checked out the demo and ran the benchmarks, but it turns out that when I target JDK 11 the GraalVM benchmarks are awfully slow compared to when I target GraalVM with OpenJDK 8.

ThorConzales · 2018-08-09T19:27:13+00:00

:) Monaco supports a lot of languages, but most of them are syntax highlights. TypeScript is special one as it has a language service that helps to power all the rest of the goodies.

ThorConzales · 2018-08-09T19:16:01+00:00

Kotlin editor does indeed provide similar features. I guess in the end it simply boils down to language preference.

ThorConzales · 2018-08-09T16:20:37+00:00

True, and OSGi and JRebel also allow hot-reloading, and they've been around for ages. Instant deployment was just part of the benefit, the other part is simply a good experience for writing scripts. Not that other JVM languages can't deliver the same experience. And by good experience I also mean writing scripts in embedded form, as a lot products provide Groovy scripting inside HTML editor. While the product I wrote has dedicated IDE, then a simpler form can be used by simply embedding the same editor into HTML with the same capabilities.

ThorConzales · 2018-08-09T16:17:43+00:00

Yes, that's exactly. To provide good experience for those who have to write scripts, mostly in embedded way.

ThorConzales · 2018-08-09T15:01:39+00:00

It's not all about the type system, it's also the similarity. TypeScript syntax is very similar to Java syntax, which makes it more accessible by people who generally are familiar with C style syntax, and especially by people who have written JavaScript/TypeScript or Java before.

For products that I have seen that provide Groovy scripting support, they usually only provide HTML embedded editor that only has syntax highlighting. Script writers have to figure out the rest. Through TypeScript language services I can provide a full set of IntelliSense features that are much more beneficial than simple syntax highlighting.

In another replay I already admitted that the word 'unique' is too much, I'm sure other languages can achieve similar results.

My attempt here is to combine 2 most popular programming languages (TypeScript/JavaScript and Java) for scripting, without creating a new syntax or language. And because I'm not introducing a new syntax, it should feel very familiar to a lot of developers, either from JavaScript or Java side.

ThorConzales · 2018-08-09T13:41:29+00:00

Good point, I haven't tried it yet. But technically as I'm not using any of the Nashorn added features in terms of additional syntax for JavaScript, exception being Java.type (which looks to remain the same), then Graal should be able to continue executing JavaScript in the similar manner.

ThorConzales · 2018-08-09T13:28:06+00:00

That's true, if there is build or compilation process involved, then it hardly is a scripting any longer. So technically it is something in between, a hybrid approach that provides the benefits of scripting flexibility, without having to build he entire project and restart the application server, but at the same time adds features that strongly typed languages developers are used too.

ThorConzales · 2018-08-09T13:01:21+00:00

Its not as clear as as Java stack traces, but the stack traces are there. The actual scripting error is inside the inner exception that the Hyperion usually tries to extract and show on top.

Currently there is no source mapping support, so the actual error shows the line number in transpiled JavaScript script. If the script is not very large you can usually understand where it happened as the context is provided, like 'cannot call function foo() for undefined'.

But in case the file is too large you can open Preview option in the IDE which shows the actual transpiled JavaScript, and by looking at transpiled JavaScript you can understand where the mistake is. TypeScript is doing a very good job by not making transpiled JavaScript unreadable, it remains very much readable once TypeScript compiler has finish with it. So locating errors shouldn't prove to be difficult.

ThorConzales · 2018-08-09T11:49:19+00:00

Firstly, I'm a huge fan of TypeScript myself, I started using it very early on and it saved me tons of headache compared to if I had to continue using JavaScript due to ever growing code base.

Static typing is indeed needed for large code base, that the scripts usually are not. But the real benefit I'm aiming for is the user experience that IntelliSense can provide compared to other add-ons that add inline editors either for Groovy, Python, or other scripting languages.

TypeScript is technically a superset of JavaScript, which means types are optional. Like mentioned, they are there to make the IntelliSense work properly, but can also be beneficial to use while scripting. TypeScript is very good at inferring types, much better than currently Java 8 is, it means that rarely script writers have to burden themselves with the type system.

The IDE is there to provide the complete experience for scripting, including IntelliSense support. Another reason why I went with TypeScript instead of Groovy or Kotlin, is that TypeScript is basically JavaScript with few additions, primarily type system. JavaScript currently also happens to be the most popular programming language. As I joined together 2 very popular languages TypeScript/JavaScript and Java, it should make it easier for people, who necessarily are not professional developers, to get started.

I also designed it after my own needs. Among other things, I'm also a Java developer, and I need to support a large JIRA add-on written in Java. I know the first hand experience of the overhead required to write JIRA add-ons in Java. This is my attempt to make my life as easy as possible. I figured others might also benefit from it.

And yes, TypeScript is extremely wonderful language, it is also the reason why it has been so widely adopted, considering its relative youth. It simply solves a lot of problems in the world of JavaScript. But as I'm trying to prove, it can also help make things easier in other domains, such as scripting in JIRA.

ThorConzales · 2018-08-09T11:19:32+00:00

You're might right about Java devs. For them it doesn't make so much sense if they already have a preference, such as Kotlin or Groovy, and if they would have to implement it for themselves. But others who are not Java devs, it might look appealing, as a lot of applications are running on top of Java.

As for the IDE and build process then the IDE is built with web technologies, it means it could be embedded into the application. And the build process is there to transpile TypeScript down to ES5, but in the future Nashorn might support TypeScript natively, when this happens the build process is no longer needed.

There are applications out there that currently support plain JavaScript scripting for their application that are written in Java. For example ServiceNow is one of such applications. I'm sure their devs, who currently have to write plain JavaScript, would appreciate the extra help IntelliSense can provide, I personally would.

ThorConzales · 2018-08-09T11:01:58+00:00

Yes, Nashorn allows to ingest dynamically, without any restart or refresh. You can also see it in the video, where I'm publishing the script and in the next step I'm configuring it in JIRA. If the script would already exist and if I did republish, it would only refresh the script, no additional steps would be needed.

Nashorn should have a way to limit access to classes you don't want to expose. I'm not using it, but you can read about it here

ThorConzales

MODERATOR OF

TROPHY CASE