I would love to see Python running natively in the browser and to be able to use Python instead of JavaScript.
You can try wasm based approaches. Some related frameworks:
https://github.com/pyodide/pyodide
https://github.com/wasmerio/wasmer-python
Back-end languages are coming to the front-end
161–170 of 328 posts
Re: Back-end languages are coming to the front-end
#162Funnily enough, PHP (like, old school PHP) is a surprisingly neat fit for this style of programming when combined with htmx[0] Tiny amount of glue HTML attributes, a heap of partials that are your PHP files and you’re good to go. What is old is new again I suppose: we used to do this with PHP and jQuery once upon a time too — though LiveView and similar are far nicer of course. I’ve been working on some personal tool…
Call me a heretic: I love PHP.
Heretic!
Re: Back-end languages are coming to the front-end
#163There is not BE or FE lang. The browser (the universal VM) just only takes JS and WASM at the moment. So they can be considered browser NATIVE. TypeScript is not native. Is it then also a BE lang? What is happening here is a big rift in the programmers community between the "I'm productive in it so it is great" and the "I prefer to use strong typing and proofs to ensure it does not break at runtime". And the second g…
> "I prefer to use strong typing and proofs to ensure it does not break at runtime"
This has not been my experience with C++ (segfaults etc.) or Java (runtime introspection and exceptions). In ye olde languages compilation seems to be mostly (more than 50%) motivated by performance rather than correctness. Compiled languages have been doing steadily more compile-time work and improving ergonomics lately.
Re: Back-end languages are coming to the front-end
#164There is not BE or FE lang. The browser (the universal VM) just only takes JS and WASM at the moment. So they can be considered browser NATIVE. TypeScript is not native. Is it then also a BE lang? What is happening here is a big rift in the programmers community between the "I'm productive in it so it is great" and the "I prefer to use strong typing and proofs to ensure it does not break at runtime". And the second g…
I don't consider myself very opiniated on tech. But if there is one thing I am adamant about is that strongly typed languages are a must in any project that's meant to grow and last. It's a must to explore, understand and refactoring the codebase while maintaining your sanity. The tooling for dynamic languages is just not there yet. So it's not a rift as much as the fact that one camp is just plain wrong.
No post body was provided.
Re: Back-end languages are coming to the front-end
#165Earlier quoted context omitted.
"in any project that's meant to grow and last" I specified what I am talking about. Weekend projects are not even a contention point. People code them in Brainfuck and we all have a laugh about it. It's the stuff that end up at the job that frustrate us where you end up assigned to a 100k (or even just 10k) lines of javascript inferno hell. Because some dev thought he can develop "faster" in Javascript.
Adequate testing goes a long way in dealing with that. If you don't have tests you're screwed either way.
This is wrong; tests and type systems have different purposes. One helps prevent logical bugs and regressions in your code, while the other enforces the correct use of code and data structures. They overlap a bit, but all the unit tests in the world can’t give you the guarantees that a type system does. And that’s without even mentioning the benefits to discoverability and documentation that a static type system gives you.
Re: Back-end languages are coming to the front-end
#166Earlier quoted context omitted.
> What is happening here is a big rift in the programmers community between the "I'm productive in it so it is great" and the "I prefer to use strong typing and proofs to ensure it does not break at runtime". I think the opposite, the rift has been healing. It seemed that it was pretty big in the 2010's (Python/Ruby/Perl vs Java/C#/C++) but these days we have TypeScript, Rust, Kotlin; Java and C# are getting better t…
> healing > these days we have TypeScript, Rust, Kotlin; Java and C# are getting better too (type inference), Python and Ruby are getting typechecking everyone caves to the types. i think the strongest holdout is probably the LISP/Clojure corner. they have optional typing for along time, but it is not used that much afaik many have voiced their reasons for liking dynamic typing. i only have one: faster reload cycles…
> everyone caves to the types.
In a way, but static languages have also heavily invested in ergonomics. Type inference is the best example I think. On the other hand, there are also other stuff like immutability that's getting popular in both languages. It seems like 10 years before you had to choose between developing software fast and developing reliable software, these days it's easier to have both.
Re: Back-end languages are coming to the front-end
#167Earlier quoted context omitted.
> I did not mean to disparage it just because it was developed for a particular domain. Fair enough, that's all I was saying. I'd agree with you that the increased use of Node everywhere to build applications, with tools like Electron, is an utterly stultifying trend. It's fantastic for I/O-heavy 'server'-type code, and for using JS as an at least surprisingly performant interpreted language, but it's disappointing t…
My CS advisor in undergrad stirred a love of safety in me with Ada. I've always wanted to get back into it. Recent headlines have made me think that Rust will move in that domain. In 10 years, probably a lot of safety-critical systems will use a lot of Rust. Ada was (to my knowledge) never particularly well accepted by "the masses", whereas Rust is. It was just too early.
Oh, nice! No, Ada doesn't seem ever to have achieved the same mainstream adoption, or at least awareness, that Rust has. Which is startling to me, because it's comparable to Rust in performance while being far far greater in safety, including inbuilt support for design-by-contract (honestly I feel like I'm shouting at a brick wall trying to get people to understand the benefits of DbC; Rust's type system is only a first-order approximation).
I agree that the problem seems to be that most 'practical programmers' don't understand the benefits of PL-research-y features, until they're forced to use it and then suddenly it takes off (cf the growth of ADTs or dependent typing after TypeScript introduced people to them).
The other problem is the perennial 'trendyism' in programming, which I hate. People won't investigate interesting languages from the 80s with unusual features; only once something's added to the JS framework du jour does it achieve wide adoption.
Re: Back-end languages are coming to the front-end
#168Earlier quoted context omitted.
> Somehow, since browsers are well accepted, node.js is a reasonable benchmark for embedded systems performance [3] NodeJS relies on V8, which is perhaps the world's most highly optimised interpreter (/JIT compiler/runner), and a spectacular piece of software. The v8.dev blog alone is fantastic reading for anyone who works on compilers, as I do. I don't like the 'dev' tendency in the programming community, to just ha…
> NodeJS relies on V8, which is perhaps the world's most highly optimised interpreter (/JIT compiler/runner), and a spectacular piece of software. Uhm, has V8 come anywhere near LuaJIT's performance by now? And LuaJIT is basically a one-man effort.
To be fair, there's a bound how much the JIT/interpreter can do for a given language. Lua is a lot simpler, and a lot easier to optimize as a result, compared to JS.
Re: Back-end languages are coming to the front-end
#169Earlier quoted context omitted.
> NodeJS relies on V8, which is perhaps the world's most highly optimised interpreter (/JIT compiler/runner), and a spectacular piece of software. Uhm, has V8 come anywhere near LuaJIT's performance by now? And LuaJIT is basically a one-man effort.
Sorry, I should have been clearer: I meant that it's had the most manpower dedicated to optimising it, not that it's necessarily the most optimal . It's hard to make apples-to-apples comparisons in that respect, given the significant differences between different language specifications. (For instance, it's hard for anyone to write a reference-compliant interpreter for Python which is as fast as the interpreter they…
That is precisely the point jvanderbot made: nodejs has less-than-optimal performance, and not for lack of trying to improve it. Its hard to write fast implementations of js or python, so they should not be used where speed matters.
Re: Back-end languages are coming to the front-end
#170There is not BE or FE lang. The browser (the universal VM) just only takes JS and WASM at the moment. So they can be considered browser NATIVE. TypeScript is not native. Is it then also a BE lang? What is happening here is a big rift in the programmers community between the "I'm productive in it so it is great" and the "I prefer to use strong typing and proofs to ensure it does not break at runtime". And the second g…
That rift has existed for a long time.
There are some programmers who don't really care what tools they use as long as they feel productive. They shy away from things like types because it feels like it slows them down.
Then there are programmers who care a lot about tools because it feels like the wrong tools hold them back and cause undue stress in the long-term.
Hot take: The first type are less mature programmers :)