Alternative to Javascript

Hi

I'm developing a "cloud"-music-manager (imagine beats or cherrymusic) for at least five years and had the insane idea to make it open source.
Before doing it, I need a GUI better than the "hacked" one I use now.
Until now, only the "player" has a web based UI; the management is done using command line tools.

This web based UI is written in JavaScript with jQuery 3. The JS client is connected to the python server using websockets.
Beside the fact that the web UI is optimized for only my setup (Firefox and a handful of screen resolutions) it works quite well.
But I need a web UI for the management parts of my manager

My main problem is JavaScript.
I really hate this language and even if I love lowlevel languages, JS is too low level for UI design.

I need a highlevel language that supports OOP.

I need to have access to the DOM

I don't need things like bootstrap, jquery (plugins) and so on.

So, my question is: What are good alternatives to writing a web UI in JS?

Kotling to JS:+/- Lowlevel but OOP is possible- The example code from documentation does not work -> bad documentation?
- Young, less known language. Is Kotling already suitable for large projects?(+) New language for me and I could use it for playing with android app dev -> Bonus + therefore

A Python interpreter inside the webbrowserBrython+ Highlevel language
+ The "same" language I use for the server/manager- Only a subset of Python ?
- IMHO a more or less dirty hack

Compiling C++ to webassembly:+/- Lowlevel but OOP is possible+ "Native language", no ugly transcoding? DOM manipulation possible?- It is C++. I like C++ for lowlevel stuff like software for embedded systems. But I'm not sure if this is a good language for highlevel applications.

At the end I have now idea how to get rid of writing JavaScript code.
Does anyone have experience with one of the methods I mentioned above (Transcoding, Python-Interpreter-In-The-Browser, Webassembly)?
Or maybe a totally different approach?

Ultimately you will be using javascript at the browser level. As you've discovered though there are some solutions where you code in a different language then compile it into javascript. I happen to like javascript so I haven't tried any of the alternatives but from what I understand Coffeescript and Typescript are popular options.

Angular is a framework for developing web based applications and makes use of Typescript as it's primary language. It might be worth looking into.

Angular or other frameworks are a good idea in general.
I had a look at angular two years ago and decided that such frameworks just make everything more difficult to maintain.
The problem is, that they implement highlevel concepts so that the work that has to be done by the developer looks really nice on a sheet of paper. But implementing everything has the disadvantage that not just the framework but also the developer has to push javascript to this high level of abstraction the framework uses.
This makes the code very hard to read and maintain. It's write-only code.
And this is exact the problem I have now with my web UI. It is implemented in such an abstract way (not as abstract as Angular, but also very modular), that there is too much javascript for just handling the abstraction.
It's everywhere in the code and covers the solution to the problem the code is made for. Just because the code solves two problems at the same time.
The one the developer wants to solve for the software, and one to make javascript work as he wants.

There is another way I had not mentioned because it does not work for me.
But just to make this thread complete and maybe inspire a better working solution, I'll post it anyway.
I use the websocket connection to only transfer data using JSON format.
The whole UI creation including not just some UI elements but the whole view is done in javascript.
For example, if the user selects an album, a list of songs, artwork and flags were sent by the server to the client in JSON format. Then the client creates the album view.
This could be done in a different way:
The user selects an album. The whole view gets created by the server (in python) and sends the html-code to the client. Then the clients JS only has to handle some callbacks for input elements.
I cannot use this solution because my ISP only allows 300kbit/s upload. So the UI must be created on client side.

Serverside UI creation+ Can be done in any language- High traffic
- A second API. The highlevel HTML-View API does not replace the lowlevel data-only API

I'm not sure why you think this. If this were actually true then nobody would use frameworks. Unless your actively trying to work against the framework conventions then they a generally help you produce much more reliable, consistent, and maintainable code. I've been developing an application using AngularJS (now an older version of Angular) and while initially getting used to it was a pain now that I have a decent understanding of how it works the application is very easy to work on and develop.

I've not tried the newer angular but as far as I know the primary reason it prefers people use Typescript is because Typescript makes things easier to maintain at the source level, then you just let the compiler take care of the dirty details of how to implement things in Javascript. That's the general idea with most of these compiles-to-javascript projects. For example some OOP concepts like classes and encapsulation are a bit of a pain and messy to do in traditional javascript. Typescript provides a better syntax for such features resulting in more maintainable source that compiles into the ugly javascript mess the browser needs.

Obviously each solution is going to take some time to get familiar with and learn how it works. It took me a couple months and a couple re-writes to get reasonably familiar with how AngularJS is intended to work and what all the best practices are for writing good code, and I still probably could be doing better to be completely honest. They key is to learn to work with the framework rather than trying to do things like you've always done before. Trying to be stubborn about change just results in frustration and poor unmaintainable attempts to make the framework do things your way.

I looked at AngularJS previously. Today a took a look at Angular 4 that uses TypeScript. It looks much more cleaner thanks to TS.
The entry will be hard because Angular 4 does not have builtin support for websockets, but I found several implementations on github in a quality range from "WTF" to "This will be helpful".
I guess I can port my current JS websocket listener code quite easy to Angular 4.
I'll give it a try at the weekend.