I have seen a .NET project that did something similar to this, it was called Bridge. That was 8 years ago no sure if it's still available.

Websharper[1] lets you develop web apps all in F# or C#. Its reactive HTML layer is particularly useful.

1: https://websharper.com/

These days, in the .NET ecosystem, there is Blazor. You write your whole web app in HTML, CSS and C# (frontend and backend). There are several different deployment models; Wikipedia gives a good summary:

https://en.wikipedia.org/wiki/Blazor

Thank you really appreciate that!

In java I know of https://www.webtoolkit.eu/jwt/

> And where are the equivalent libraries for Go, Rust and Java?

Not aware of anything yet for Go/Rust, but Java and Python have had libs like this for a while now (to the point that Pyjamas hasn't been updated in a decade):

* GWT (Java)

* Pyjamas (Python)

* Vaadin (Java)

Those are general purpose. After that you have the sci/data-oriented python frameworks like dash, streamlit, etc.

One for C++ is

https://www.webtoolkit.eu/wt

by https://www.emweb.be/

Well, I haven't looked into this one deeply yet, so I'm not sure what the differences are exactly. But there are many existing, broadly similar, projects. I see this as a solution to "I want to make an interactive website, and I don't want to touch the JS ecosystem at all and/or I really prefer python-specific libraries". This is my position exactly, so I sort of keep track of what's available. From that perspective, this is in the same space as: web2py, pyjs, streamlit, brython, pyodide, pywebio, gleam. I'm sure there are others.

Useful list. Dash & bokeh as two more in the space

https://github.com/plotly/dash https://docs.bokeh.org/en/latest/

This is a futile pursuit simply because you are creating a layer of abstraction over JS using another dynamic language so there's no real gain other than syntactic sugar.

Would you say the same thing about web assembly and emscripten? At least one of the above is based on those.

Using scientific and numeric packages from the python ecosystem is more than syntactic sugar, IMO. It seems like the JS world mostly ignores that stuff.

I have yet to try a real project with any of those python web tools. I know just enough HTML, vanilla JS and DOM API to cobble together ugly sites when I need to, so that's what I do. But I am optimistic that a better alternative will emerge eventually.

These tools are a waste of time. They take longer to learn then basic js and then in 3 years support is dropped you might have well learned a bit more js.

It's a bit big but just run nextjs, it solves almost everything for you. Even deployment is one click away. Would take 5 mins to get started. And a few hours to understand for a seasoned dev.

Haha yeah its amazing how the lengths people will go to not learn something simple but new!

I have been using JavaScript for decades, and I have never liked using it. I want to enjoy making interactive browser-based apps. Sorry that I don't buy into the cult of infinitely complex front end build tooling.

I am consciously opting out of that ecosystem because it isn't for me.

I'm not familiar with nextjs, will try it out.

I honestly want to understand this viewpoint, so I can make informed decisions when looking at these tools. So let me ask...

I agree that some of these older python things are probably not worth using. But I'm a bit confused that you're entirely dismissing web assembly. I think it's well understood that using JavaScript as the foundation of front end software was a complete historical accident. It's a huge amount of inertia to compete with, but that doesn't mean it's insurmountable.

My understanding is that wasm is a major industry initiative, and it isn't going away. Emscripten seems to be nearly as stable. Now, maybe two or three non-js languages will emerge as the core of wasm-based development, and maybe python won't be in that small group. I'd rather learn, say, rust than continue writing JavaScript.

Where do you disagree? You think wasm will be shut down completely in a year? You think none of these languages will take off in terms of web-specific tooling? Something else?

Whether it was a mistake or not. It's taken over. And many people have worked hard to make it a modern language the last 20 years.

I've seen many attempts to take over js, thusfar they all failed. At the same time JS got more and more powerful.

Js is so integrated in every corporate it will not go away any time soon.

JS solves so many issues know and the css layout is much more mature than then any under native system (native apps, flash etc are much worse at responsive layouts)

Wasp sounds fun, it's very early stage and doesnt sound like it has anything to do with webpages but runs a binary in a browser sandbox. Kind of like flash without a plugin. Can have a lot of cool features, mainly games etc. But sounds like an addition not a replacement. But who knows!

The frontend gets compiled to JS, not unlike how TS gets compiled to JS.

Bokeh, Dash, Gradio, Pglet, Idom, Anvil

I think all LiveView frameworks should be part of this.

Here are two Python ones I've tried:

https://www.django-unicorn.com/ https://github.com/edelvalle/reactor

actually, as per the docs the framework is converting python code to Javascript. So you would need to JS skills to debug.

Most of the problems in web front have been solved in JS (think CSS styles, state management) re-writting it in python would be pain, especially when everything compiles to js

Our goal is for the user to never have to see JS. We try to catch most errors in Python during compile time. We're also not trying to reinvent things like CSS styles, just make them accessible in Python.

> We try to catch most errors in Python during compile time.

I feel Python is not the best language for catching most errors during compile time.

We're using Pydantic and our compiler has custom type-checking on top of Python to catch these issues.

That's not gonna happen if they have to solve browser runtime errors. And with there being so much variance between browsers and random nonsense to hack around, how can you possibly get around that?

Besides, python and js are so similar it's really funny to see people not wanting to use one but cling to the other.

The available libraries are quite different between the two languages.

Does this thing also convert python libraries for use on the web? Can it compile say keras or pytorch to javascript? I guess that would neat to have on the browser client side.

I don't know much about Pynecone, but that is indeed what pyodide does:

> These include many general-purpose packages such as regex, pyyaml, lxml and scientific Python packages including numpy, pandas, scipy, matplotlib, and scikit-learn.

Again, not super familiar, so I don't know the level of effort required to support these libraries. Maybe adding pytorch would be infeasible, maybe they just need enough people to express interest.

https://pyodide.org/en/stable/

State management hasn't really been solved.

Hence the whole debate about signals vs no signals last week. :)

I didn't catch that and can't find it, got a link?

XState is the bee's knees if you're writing any Javascript

https://stately.ai/viz/2ac5915f-789a-493f-86d3-a8ec079773f4

Java does have Vaadin but it's a mostly proprietary software. But it is very good and largely under appreciated.

Maybe I am an optimist, but I'd say Vaadin is mostly Open Source (Apache License). You can build complete web applications with the open source version. Only some advanced components (e.g. an Excel-like grid, a WYSIWYG editor, Highcharts components) are proprietary and require a subscription for development, while the builds can be freely distributed.

So ruby has a JS transpiler - opal - https://opalrb.com/

I tried using it a little bit but the reality is if you need JS to make your app more interactable it's really worth it to just learn some JS. As soon as you need something complex the extra layer of abstraction just gets in the way and becomes more of a headache, and if you don't need anything complex then you don't need a fancy JS solution in the first place.

JS only becomes complex when you are trying to create an enterprise version of your app along with a build platform. You can always just sprinkle in <script> tags in your HTML for simple one liners without getting into the weeds.

JS is complicated because the browser environment is complicated.

If it's going to be rendered by and live in a web browser it will either be complicated or limited in some way (like low code/no code tools).

That's not really true. It's complicated because the language is one of the worst to manage.

It's not really any worse than Python or Ruby, but you also get TypeScript which helps

I posit that it is both.

Dealing with interactivity in the browser is subtle, complex and full of edge cases. JavaScript is also a horrible, broken language that’s not really fit for purpose. We’ve collectively invested a lot of time and resources trying to improve the experience of working with it, but the point still stands.

I'm working on https://github.com/mayu-live/framework which is 100% server side Ruby. It's kinda like React/Preact, but server side, and Ruby. No JavaScript required (it's not even supported).

That's pretty neat. In general I think stuff like this is cool and works pretty well as a starter kit for simple CRUD apps if you don't already know Rails + JS, but like I said in my OP, once your app gets more complex, you hire some UX designers and you try to make your app more interactive, not having easy JS access makes it hard to do interesting things.

So could be useful for small projects but I wouldn't pick a solution like this for projects I would want to grow larger

You are assuming people use Opal because they don't want to learn JS. In reality it's that JS is a very messy language compared to ruby.

You can be a lot more productive if you avoid JS entirely.

JS is a totally fine language. The entire browser ecosystem makes JS an incredible productive language for working on the web. You can disagree if you don't like the language personally but that doesn't change the fact JS gets the job done

"incredible productive language for working on the web"

You can disagree if you want but that doesn't change the fact that JS is a huge pain in the neck to get the job done with.

Absolutely agreed, hence the many Python to JS transpilers out there.

https://transcrypt.org https://yourlabs.io/oss/ryzom#javascript https://github.com/am230/py2js

We get so much satisfaction out of writing JS in Python, it's worth all the IDEs in the world for us!

> My only question is why it took so long for someone to implement it?

Uhhhh. Because it didn’t. Google GWT was huge on the hype cycle about 15 years ago.

You know this has been done before over a decade ago, multiple times in Java and Python.

Not saying the space can’t be improved upon but I fail to see how it’s any more revolutionary now.

> My only question is why it took so long for someone to implement it?

This is by far the first front-end python implementation/framework. Skulpt, Brython, Anvil, PyFyre, PyScript, PyWebIO, and the list goes on…

Serious question, why not Typescript? Are you not aware of it or do you have other reasons?

You may not realise this, but TS is just JS + Types.

You may not realize this, but that makes all the difference in the world.

You may not realise this, but this post is about a framework that let's python devs make modern web apps without touching the JS ecosystem.

The root comment appreciates the framework, and shares their unwillingness to write JavaScript and HTML. The reply to that comment asks why don't they try TypeScript.

I think that reply is absurd because asking someone to write TypeScript when they dislike JavaScript in the first place is absurd.

I know and realise the fact that JS+Types is way better than plain JS, and infact I write TypeScript on everyday basis.

> I think that reply is absurd because asking someone to write TypeScript when they dislike JavaScript in the first place is absurd.

I don't think it's absurd to ask someone to try Typescript first before jumping through hoops just to make Python run on the web, which certainly brings a lot of problems of its own. You do have to actually try it to see how it's a completely different experience, even if the types are just bolted on.

.NET has Blazor, seen something similar in Rust. I believe there are tons of similar libs

Hmm? In 90s and 2000s most web frameworks did not rely on JS at all, they were completely server-side. I.e. the server renders a page. User clicks a button, browser collects data from a form and sends request to the server. The server updates its state and renders a new page. There are some downsides to that approach, but it can be pretty good if you just need to get some information and/or let user browse a data collection.

Compile-to-JS approach started to appear in mid 2000s.

Nope, but something better, e.g. Leptos for Rust which enables you to write Rust code and RsX (JsX equivalent) that runs on the server until all WASM is loaded to run it in the browser