Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Back-end languages are coming to the front-end

github.com

Post reply on HN
Print view View original

181–190 of 328 posts

Re: Back-end languages are coming to the front-end

#181

Post by [deleted] »

serverholic wrote: post #170
cies wrote: post #77

There 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…

[deleted]

Re: Back-end languages are coming to the front-end

#184

Post by 2ion »

Ha. WASM with QtCreator and Qt w/ C++ would have put a decade of web developers out of a job had it launched in 2010. Most amusing about front end is that stuff like flexbox, nice animations and GPU-accelerated graphics based on web tech get praised and hailed as innovation yet we had that stuff on the desktop for years and years already way before the web bros rediscovered everything 2010-2020.

Re: Back-end languages are coming to the front-end

#185

Post by Supermancho »

RussianCow wrote: post #165
Tade0 wrote: post #114

Earlier quoted context omitted.

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 give…

> This is wrong; tests and type systems have different purposes.

For decades, companies have prospered without a strong type system and using tests for type assurance ad hoc. Usually when it's worrisome or has been problematic. You can say it's wrong (conceptually, theoretically, etc) and yet it people continue to do it. That's interesting to think about.

Re: Back-end languages are coming to the front-end

#186

Post by samhw »

yccs27 wrote: post #169
samhw wrote: post #158

Earlier quoted context omitted.

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.

> nodejs has less-than-optimal performance, and not for lack of trying to improve it

I think you mean "less-than-C" performance, no? I'd say it's pretty close to optimal performance - it's just that the optimum is not that high compared with a stricter language, or indeed a compiled language, which are able to exploit far more invariants (especially in the latter case).

Anyway, I think his point was fundamentally correct, but it just seemed like an odd choice to single out one of the world's best interpreters - and one which is fairly competitive even with fast compiled languages - as your example. If he'd chosen CPython, I'd have been with him all the way, haha. (As someone who's written a faster Python interpreter, ...don't even get me started on that one.)

Re: Back-end languages are coming to the front-end

#187

Post by everforward »

mrtksn wrote: post #135
jvanderbot wrote: post #108

Earlier quoted context omitted.

I actually appreciate domain-specific programming languages. It's fine (for me) that JS is the native front-end language. It's fine that Rust targets systems and embedded. I love that Python is a middle ground, and really great backends are built on it. I'm great with C being a really low level language that forces me to think about the machine. Taking "I'm productive in it so it is great" to an extreme, we end up se…

JavaScript itself is very powerful in its own domain(the DOM interactions in the browser) but most of the bloat comes from developers wanting to write JS in different way than originally designed. 20 years of JS frameworks and at the end of the day all they do is arranging HTML boxes through slightly different code. But why so many frameworks for the exact same output? It usually comes down to code management and mak…

> JavaScript itself is very powerful in its own domain(the DOM interactions in the browser)

Imo, most of this benefit comes from being effectively the only way to interact with the DOM up until WASM (and I think I read that WASM still calls out to JS for DOM manipulation). If Python had a way to manipulate the DOM via shared libraries or something, I'd wager there would be equally powerful Python libraries (ignoring security concerns).

Or phrased differently, I don't think anything about the design of Javascript is uniquely well suited to manipulating DOMs, it just has a monopoly on manipulating the DOM.

> most of the bloat comes from developers wanting to write JS in different way than originally designed

I think a big part of this is that Javascript has become a much more integral part of websites than it was originally intended to be. My impression is that it was designed to add a little bit of interactivity, not for people to ship a nearly blank HTML file and then fill in the entire page using Javascript.

That's not to say it's a bad idea, I just don't think it was designed for that and we have some warts and a lot of changes to allow us to implement that modern paradigm. I strongly suspect some form of parallelism would have been included if we had known what modern frameworks would look like.

Re: Back-end languages are coming to the front-end

#189

Post by zo1 »

rafale wrote: post #91
cies wrote: post #77

There 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.

My 2c. Typed languages justify themselves being typed by virtue of the complexity they themselves impose.

We say they help us with solving a complex problem but I'd say they are the ones that make the problem more complicated than it needs to be.

Yes they have their uses, but those are few and far between. The rest is just devs solving how to do what they want whilst keeping the compiler happy with whatever IBaseAbstract virtual template method thingimabob method the compiler needs.

Re: Back-end languages are coming to the front-end

#190

Post by samhw »

danachow wrote: post #179
samhw wrote: post #158

Earlier quoted context omitted.

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…

Well you did say: “ NodeJS relies on V8, which is perhaps the world's most highly optimised interpreter (/JIT compiler/runner)” But even in manpower this is pretty hyperbolic compared to Java and .NET. There was probably more manpower in even some of the third party Java runtimes like Azul.

> Well you did say: "NodeJS relies on V8, which is perhaps the world's most highly optimised interpreter (/JIT compiler/runner)"

Yes, and that's exactly what I meant. It's undergone the most optimisation. That doesn't mean the result will necessarily be more performant than some other interpreter for a different language which is simpler to interpret. By that logic, I could write an 'x86 interpreter' which would blow LuaJIT out of the water...

> But even in manpower this is pretty hyperbolic compared to Java and .NET.

I wasn't including Java because it's not strictly an interpreted language, though I admit you could write a whole book about the philosophical differences between V8's abstract machine vs Java's bytecode VM. .NET I don't know so much about. As far as I'm aware, .NET hasn't had as much manpower invested, though Java has & would certainly beat V8 if you included it.

Post reply on HN