Live data from Hacker News

Back-end languages are coming to the front-end

github.com

111–120 of 328 posts

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

#111

Earlier quoted context omitted.

After having been in this industry for 20+ years, I can pretty confidently say the world of software will never wake up. It's just been an endless cycle of adding abstractions, removing them again, using back end languages on the front end, using front end languages on the back end, using relational databases instead of a key value store, using key value stores instead of a relational database, unit tests over integr…

I think it's a maturity thing. I've found myself going from wanting to use cool technology to build whatever to wanting to use boring technology to build cool software. A few decades of programming has taught me that cool technology inevitably turns out to be janky and annoying and half-finished.

I agree it's a maturity thing, but I wouldn't say the cool technology 'inevitably turns out to be janky and annoying and half-finished.' I think it's more that the cool technology is developed for a certain use-case and, developers being the way we are, we pick up our new hammer and proceed to test if every object around us is a nail.

We also won't accept other people's test results. Sure, 80 other devs have said this isn't a nail, but are they SURE?

It's not the technology's fault.

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

#112
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…

Agreed. Javascript is increasingly something that is optional. You can use it but you no longer have to use it. And even if you are using it, you are more than likely transpiling it. Browser side Javascript is just a compiler target at this point. There are a minority of people not doing any transpilation of course. But at this point that really is a minority (and by no small margin I'm guessing). Nothing against that, but "native" javascript just stopped being a mainstream thing quite a few years ago.

That doesn't mean Javascript will go away but it does mean it now has to compete on merit rather than relying on it's status as the only thing that you can actually use in a browser. Many projects have already shifted to using Typescript for example. And from there to other transpiled languages is not that big of a leap. We use Kotlin-js for example. It's great. Other people use clojure, vue, elm or other languages that basically aren't javascript but that just happen to transpile to it.

Long term WASM is a more efficient compiler target. Smaller, faster, easier to deal with for compiler builders, etc. The only remaining reasons to target browser js with your compiler, is that it still has better bindings to the browser APIs. This is something that is being worked on and of course that is more than offset by being able to compile existing libraries to WASM.

WASM has a few other things as well that are still being worked on (threading, memory management/garbage collections, etc.). But long term, anything that javascript can do in a browser would be something you could do from a WASM compiled program as well. Once that works well enough, a lot more languages will start targeting browser applications just because they can. And a lot of developers that don't necessarily care about downgrading to Javascript might have a go at doing some applications that run in a browser. I predict a little renaissance in frameworks and tooling for this.

And of course with WebGL and Canvas, using the DOM and CSS is entirely optional. For example Figma has a nice UI that looks like it would be hard to match with anything DOM based. They have a bit of react on the side for the bits that don't really matter but most of the app is C++. People also run games, virtual machines, etc. in browsers. There might still be valid reasons to use DOM + CSS like we have been for the last two decades. But it won't be the only choice for doing UIs. And being limited by it like we have been is increasingly no longer necessary either.

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

#113
post #111

Earlier quoted context omitted.

I think it's a maturity thing. I've found myself going from wanting to use cool technology to build whatever to wanting to use boring technology to build cool software. A few decades of programming has taught me that cool technology inevitably turns out to be janky and annoying and half-finished.

I agree it's a maturity thing, but I wouldn't say the cool technology 'inevitably turns out to be janky and annoying and half-finished.' I think it's more that the cool technology is developed for a certain use-case and, developers being the way we are, we pick up our new hammer and proceed to test if every object around us is a nail. We also won't accept other people's test results. Sure, 80 other devs have said thi…

Maybe not inevitably, but the vast majority of of yesteryear's cool technology is obsolete and forgotten today. The remaining became mature "old" technology.

There was a time Java used to be cool new technology.

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

#114
post #100
post #93

Earlier quoted context omitted.

Which camp is plain wrong? The side that insists on using strongly typed languages for a weekend throwaway project? Or the side that insists on using dynamic languages for 2000 file projects? I always see "rifts" as a lack of perspective. One solution is obviously the only best way because they only see their narrow sets of use cases.

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

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

#117
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…

Agreed. Javascript is increasingly something that is optional. You can use it but you no longer have to use it. And even if you are using it, you are more than likely transpiling it. Browser side Javascript is just a compiler target at this point. There are a minority of people not doing any transpilation of course. But at this point that really is a minority (and by no small margin I'm guessing). Nothing against tha…

Could you share some more about your experience with Kotlin js and the libraries/frameworks you use?

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

#118

I'm surprised this wasn't about WASM. Either way, I'm receptive to the "LiveView" model, but until such a time a server can deliver both HTML and server driven native UI for mobile interchangeably, I prefer the RPC approach. I don't want to develop: 1. Both an API for mobile and LiveView for web. OR 2. Create my own server driven UI paradigm for mobile. I find maintaining one architectural pattern simpler. I do want…

Didn't AirBNB try something like this?

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

#119
post #107

I just shipped my fourth large project based on Phoenix LiveView and I think it is the best thing that happened to web dev since forever. The javascript is minimal (like to manage selection in text field or to handle copy/paste). Everything else is in elixir. Tailwind is used for CSS. Having the full client state available on the backend is really incredible. It is so much easier, no more ajax/graphql... You just hav…

A question from a newcomer to the ecosystem: do you have any recommendations for an admin system like Django's? On a related note, how do you usually determine whether a package is abandoned vs stable?

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

#120
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 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…

> 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 hack stuff together and say "well, it works!", but I'm also not impressed by people trashing any high-level languages just because it's a meme they heard.

V8 is phenomenally performant and is a hard benchmark to beat for anyone and anything, even at the compiled end of the spectrum. (Yes, it's beaten by C/C++/Rust/Go, but it's not to be sneered at, at all.) I'm struggling to equal it with the highly optimised Python JIT-assisted interpreter I'm writing for my work - even after relaxing the ABI and writing sophisticated instruction-set-specific optimisations. (And I'm writing it in Rust, just to score at least one point off the cargo-cult bingo card.)

Post reply on HN