Hacker News Reader

Comment by spiderice | Hacker News Reader

You are interpreting GP’s comment very uncharitably, to the point that it actually becomes a completely incorrect interpretation.

GP is pointing out that it is advantageous to have a single language on both front end and backend. And somehow you arrived at “developers cannot be expected to learn more than one language.”

There ARE big advantages to having the exact same language (as opposed to similar languages) on both client and server, especially in an SPA where you want to render something initially on the server, but then update it using the same logic later on the client.

View on HN

> GP is pointing out that it is advantageous to have a single language on both front end and backend. And somehow you arrived at “developers cannot be expected to learn more than one language.”

Because he considers it a "barrier" to have to switch between languages to do backend-only changes. Which is a completely different use case than the one you're describing.

For an SPA where you're essentially doing frontend on both ends, yes, that's obviously easier when you're only doing it once.

But that's not the general case, and I'd argue that transitioning between different mental contexts for components you're not regularly touching is always going to be a hurdle to developers, regardless of the language used. Blaming it on the language is an useless red herring.

It's definitely a barrier to have to switch languages. You might be super familiar with Chrome's debugger UI (which is excellent, btw), and feel lost when suddenly getting dropped into IntelliJ's.

Also, what if you just have frontend developers who straight up don't know Java or vice versa? I don't see how having a shared language could ever be a bad thing.

I feel like switching languages adds extra friction too. Switching contexts is still a hurdle, but using the same language can make the hurdle shorter.

Having to write the same logic twice in two languages, and then making sure both implementations behave the same way. I don’t know if I’d use the word “barrier”, it’s certainly a significant pain in the ass.

The classic example is of course validation, but plenty of other places it can come up.

Perhaps I'm overthinking things and HTML does this naturally, but is there something for rendering that is what Swagger/OpenAPI is to APIs? Some way of specifying HTML that can be both rendered (and read back for inputs) by multiple implementations.

In theory, that's what template languages like jinja, liquid and twig are for.

But as you can see, there's n+1 standards for it, and in practice none of them has a Javascript implementation good enough for productive use. So it's more a "what if?" scenario, had Angular/React/Vue not taken off.

Reply on news.ycombinator.com