My only question is why it took so long for someone to implement it? And where are the equivalent libraries for Go, Rust and Java?
https://github.com/plotly/dash https://docs.bokeh.org/en/latest/
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.
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.
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?
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!
Here are two Python ones I've tried:
https://www.django-unicorn.com/ https://github.com/edelvalle/reactor
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.
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).
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.
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 can be a lot more productive if you avoid JS entirely.
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.
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!
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.
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
I feel Python is not the best language for catching most errors during compile time.
Besides, python and js are so similar it's really funny to see people not wanting to use one but cling to the other.
> 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.
Hence the whole debate about signals vs no signals last week. :)
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.
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 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.
Compile-to-JS approach started to appear in mid 2000s.
This is by far the first front-end python implementation/framework. Skulpt, Brython, Anvil, PyFyre, PyScript, PyWebIO, and the list goes on…