Hacker News Reader

Comment by bluedays | Hacker News Reader

I use to want this. Then I learned JavaScript, and decided it's a much better language for the browser than Python is.

And if you want types then Typescript is a lot nicer than using Python's typing stuff.

I used to love Python's list comprehensions etc, but since JS got .map, .filter, and all the other new things I really don't miss them. My impression of async is that it's much nicer in JS than in Python.

In the new version of my employer's web app we are moving from JS front-end with Python (Flask) backend to using as much Typescript as possible, and only using Python where we need data-sciency / ML libraries. We'll call out to it from our Typecript backend as-needed, but will do as little in Python (and especially in Pandas) as possible.

I prefer Python over Javascript in almost every way. But python's async is a dumpster fire. It's quite natural in Javascript.

Unfortunately Javascript makes you do almost everything async, no choices. Which makes you think that way. Which is awkward to start with and can lead to a lot of strange corner cases. In python unless you're really trying to squeeze performance out of a system you almost never need async.

It doesn't help that it feels like pythons async ecosystem doesn't really know how it works. There is all sorts of blocking code in python async libraries and no one seems bothered by it.

I guess it could be that they just don't care about this type of thing to begin with and have no idea why they are using async other than they heard "it is faster". Meanwhile I am pulling my hair out trying to squeeze a more reqs/s out of an on premise server.

python's async mostly works as long as you're using async-native libraries. if you can await it, it's okay. it only gets disastrous when you have to start mangling callback code into promises.

although i really do love javascript's ability to await synchronous functions without it causing any errors. i'm sure it's less performant, but sometimes i just don't care.

I want to love async. But it’s a nightmare to debug. To this day I still cannot debug tortoise ORM. I dont understand why I can await so easily in my browsers JS console but not in pdb.

I want to use Python more often but having to care about significant white space is a much bigger downer for me than the async being a "dumpster fire" and I also don't think async in Python is so bad.

I'm saying this as someone who has been programming in many languages since more than 20 years.

What kind of editor do you use for writing code? If you need to "care" about significant white space, it might be that you're simply using the wrong tool for the job. Working with Python since 2.4 (among tens of other languages) I honestly don't remember a single situation where I had to care...

It depends, I like using vim on a remote computer and use IntelliJ locally. It usually breaks when I'm trying to refactor, copying and pasting etc.

I was using Vim for a few years and later switched to Emacs. Both provide commands for handling indentation of lines and blocks of code. You just paste and select/mark a block, then indent or unindent until the first line of the block is aligned with the preceding line in a place where you pasted the code. It's true that you can't auto-indent on paste, though. Still, it never slowed me down noticeably. It's a trade-off, to be sure: you need to align indents manually, but then you don't ever have to deal with things like this:

    if (sth)
        sth1();
        sth2();

Yeah, the thing is, if you do forget to align things, which is a thing if your eyes are not the sharpest, weird things can happen, especially when you are writing scripts as if there's no tomorrow. Those experiments usually end up being written for the node.js runtime because I really, really hate aligning lines when I'm writing one-off scripts.

Well, Python is in general not the greatest language for one-off scripts, so it's not strange to use something else for this use case. I definitely never felt your pain, though. I think I'd have to see you edit a Python file live to understand what makes it problematic for you (for example: what width of an indent do you use? wouldn't increasing the width help you notice misalignment? and if it's about seeing/noticing, can't you make your editor display whitespace?).

In my experience, there's no syntax that would be free of gotchas and pain points - I tend to accept them, and if I'm going to work with a particular syntax more than once, I write a bit Elisp to make working around them as seamless as possible.

I totally have this problem with yaml. I wish vim had a line-these-things-up button, kinda like how % lets you bounce around in parenthesis - something like that for leading-whitespace alignment.

Same - I still like Python for scripting, and Scala is still the language I have most fun coding in, but … JavaScript got decent, and TypeScript got really good. I used to want Python in the browser, but no longer see the need.

TypeScript is just a terrific choice for basically any web SPA. My current company is full stack TS (React/TS/MobX on the web, React Native/TS/MobX on mobile, RESTful Express/TS/Postgres/Redis services), and it’s the most productive, straightforward stack I’ve ever used. Perfectly decent performance too. A single language that is legitimately a great choice for most use cases on the web, mobile and backend, hard to compete with that.

I have a similar language preference. Do you think a RESTful TypeScript backend is more productive than a Scala alternative?

I can't compare to Scala, but unless you know you need an API for a web frontend then I would take a look at tRPC or other "zero API" systems (Blitz is another one, but I'm a little unclear on where they are in their pivot).

It's a little hard to describe how magical it feels to actually use. It completely removes needing to think about an API. You don't think about endpoints, about (de)serialization, about the mechanics of fetching, or how arguments are passed. You just call you functions by name from the front-end. All your types are preserved so that if you change the signature of your backend function Typescript will catch it everywhere on front-end. If you use react-hook-form then you can export the zod validators that you wrote for the backend and import them to the frontend, and now your client-side code is using the exact same validator as your backend does. Change your server side validation and now your client-side form won't compile and you'll know exactly why.

Honestly it feels like the missing link in fullstack dev to me. Typescript brought the types and the compiler, and tRPC makes it feel like your entire back and front-end are one system.

Very interesting, I didn‘t know about tRPC yet. I remember in the early days of ScalaJS there were similar ambitions, but I believe it never really caught on.

I will definitely give it a go, thanks.

Yeah, I think even when engineers are fully ramped up, a well written TS backend is a bit more productive than a well written Scala one. They’re actually decently similar languages, both are expressive languages with expressive type systems and an OOP/FP mix, but I’d say TS has a bit less boilerplate/overhead, the libraries tend to be simpler to learn/use, and it compiles faster.

The biggest efficiency gains, though, are:

- Much faster training/ramp up time for new devs with TS vs Scala

- You can use the same language on the FE and BE, makes it easier for individual devs to do full stack work

The main downsides of TS vs Scala are:

- Scala is faster and more efficient, performance wise. Have to spend more on TS services to serve the same amount of traffic, and if you have heavy computation that’s parallelizeable, Scala is wayyyyy better at that

- As you get into more niche use cases, you just can’t beat the JVM library ecosystem, there are high quality libraries for EVERYTHING. The Node ecosystem is very good too, but not as good as the JVM ecosystem

- TS/Node stack traces are useless compared to Scala/JVM stack traces

Overall, I’ve got ~7 years of professional Scala experience, love the language, but if I was starting a startup today, I’d go full stack TypeScript.

It appears to be a pretty fantastic time for full-stack development and solo founders.

For me, the context switch between client and server was always difficult using a Scala/TypeScript setup (startup).

As you said, unless you rely on some niche technology only available on the JVM, it‘s probably more productive to go full stack TypeScript. For perf-heavy workloads I would probably pick Rust instead of Scala.

I think this thread misses the point. The motivation for pyscript is the accessibility of Python, because it can be adopted even by persons without years of programming experience. I see it regularly in my company with youngsters.

This alone makes it deserve its existence and further pursuit (“for the other 99%”).

Imagine a world where only mechanics could drive cars, because the way they worked “would be fine with him or her” but for everyone else there would be a steep learning curve to overcome initially - which most won’t embark on because there are other goals in life too.

Keeping with the analogy, normal cars are still not suited for Grand Prix racing or other heavy use cases. But this is not needed for the 99%.

Its the same with Python, its limitations, and the better suitability of other languages for a mix of specialised and performance use cases.

Creating an application is more like building your own car, not merely driving it.

I think it would be great if more people would be able to create web applications, but there should be better technologies than shipping a ten-megabytes interpreter with every HTML page.

Also Python is not easy for non-developers. It might be easy for middle school level tasks like replacing a word in a string. However if you want to use a database, you have to learn about object-oriented programming, property descriptors, ORM and decorators, all of these are difficult topics and libraries like SQLAlchemy are not for beginners (just look at its documentation. It doesn't even explain what ORM means).

> Imagine a world where only mechanics could drive cars

A closer metaphor is: imagine a world where everybody builds their own car. That would be a bit of a mess.

Isn't JavaScript also easy to learn? There are many people who have learned to use it for web development in a coding bootcamp or something and don't know much else about programming.

I don't agree that python is more easily adopted by people learning. Perhaps the older versions of python sure, with contrived "hello world" examples where there is not much going on. But with modern python it is a fucking disaster with pip and anaconda and easy_install and 2.x vs 3.x still lingering (Macs) and type hints or not and list comprehensions being incomprehensible etc and the use of indentation for scoping leading to frequent errors from people learning (I never understood why indentation was cited as a good thing for learners - please go run a "teach kids to code" class one day and you'll spend 50% of your time fixing indentation errors in their code!)

Javascript is everywhere on every device with a browser - if you can load a web page, you can start coding in javascript right away. No install needed - you have a REPL right in your browser.

Granted, NPM is a mess but that is not mandatory and it is still perfectly possible to write & ship modern production JS code without NPM or build-steps being involved. Modern JS is very powerful, and if you can stomach a build-step TS makes it even better.

That sounds frustrating, however easy_install hasn't been relevant for years, and obviously 2.x is EoL. Anaconda is generally better for beginners since it manages basically everything for you. Hardly a disaster.

You basically need NPM if you want to work with any kind of libraries, and I'd say the Anaconda system comes with way more ergonomics out of the box, so that's more or less a wash.

Similar opinion here. But another reason is now I tend to write my own code rather than depend on third party libraries and that removes one argument for making a choice.

Reply on news.ycombinator.com