Back-end languages are coming to the front-end • Hacker News Board

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

#221

Post by marcos100 » Thu, Feb 10, 2022, 7:52 PM UTC

jvanderbot wrote: post #108

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

Tokio as in the rust Tokio runtime? You think that, because of tokio, rust became more bloated? Why?

I know rust, but I haven't used async apart from their tutorial, so I'm really curious about what are your thoughts about it.

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

#222

Post by chrismccord » Thu, Feb 10, 2022, 7:53 PM UTC

anthonybsd wrote: post #216

Around 15 years ago I needed to build an internal app for my company that would aggregate and display a lot of data. Our backends were all in Java and I had sour taste for JavaScript from a previous project so I looked around for an AJAX framework that would allow me to avoid writing any JavaScript. Lo and Behold there were actually 2 viable ones on the market: Google GWT and Echo2. I played with both of them and Ech…

I remember when Sencha came on the scene :) WebSocket's help for more efficient bidirectional comms and guarantee load-balanced process placement, but LiveView can also be used with long polling if folks have a hard requirement. We also have much better DOM apis for things like efficient diffing/patching that I'm sure you lacked back then. Were you keeping stateful "widgets" on the Java side or hydrating from client state for interactions?

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

#223

Post by rglover » Thu, Feb 10, 2022, 7:59 PM UTC

What's incredibly frustrating about the knocks on JavaScript is that it's not a shortcoming of the language that creates the problems hinted here, but the poorly-considered engineering choices of the popular frameworks.

After building my own framework [1] last year, I realized just how disconnected JavaScript developers—yes, the "big boys" are especially off in CS la-la land—were from web development fundamentals. HTTP distilled down to its absolute essence is brilliant, but for some reason gets absolutely ignored in the JS world. When you couple that with websockets for incremental updates (similar to what Chris McCord is doing in Phoenix), it's insanely powerful. It can be reasonably lightweight, too, if you're only shipping the JS you need to render the page.

That rendering some HTML, CSS, and interactive JS in a browser has been turned into what it has is staggering. Though, not surprising, when you realize a lot of the momentum in JavaScript the last decade or so was perpetuated by venture capital (and the inevitable fast and cheap nature of that world) being pumped into inexperienced teams.

[1] https://github.com/cheatcode/joystick

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

#224

Post by chrismccord » Thu, Feb 10, 2022, 7:59 PM UTC

cestith wrote: post #51

It's almost like what some of us did 15 years ago, use just enough JS to load things into the DOM fetched from the backend via XMLHttpRequest, is news now. Having a Websocket open to the backend and using a front end that's aware of that instead of using HTTPS seems to be the major difference here. That difference is more about WebSockets existing now than about the choice of backend language or the server-rendered,…

The biggest difference (at least for Phoenix LiveView) is having a stateful backend represent the UI and we do away entirely with HTTP APIs/serializers/resolvers. So you get both interaction and push updates from the server at any time, without HTTP glue layers. And it actually scales. So think React's functional-reactive-templates on the server, pushing minimal diffs over the wire better than if you'd carefully written an efficient JSON API or GraphQL endpoint. Elixir is also a distributed programming language so you also get things for free like sending an update to everyone's UI across the entire cluster.

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

#225

Post by zekrioca » Thu, Feb 10, 2022, 8:06 PM UTC

Why no words about WebAssembly/WASM?

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

#226

Post by pjmlp » Thu, Feb 10, 2022, 8:08 PM UTC

BoorishBears wrote: post #219

pjmlp wrote: post #171

Earlier quoted context omitted.

> Java => Kotlin, If you are speaking of Android, yes. On the JVM is it just one more guest on the building. https://madnight.github.io/githut/#/pull_requests/2021/4

Not really... Groovy was never really in the building and is just awful. Scala is like a reimagining of the building that happened to find the old foundation useful. Clojure is like a skybridge from the Lisp skyscraper across the way. Kotlin is the only JVM language that's gained traction while aiming to be Java but better, the rest just happen to use the JVM, but calling them "evolutions" of Java would be deeply mis…

It gained traction on Android thanks to Google pushing it over their creptic Java implementation, while pretending anything beyond Java 8 never happened.

It will follow the path of every other JVM guest language.

I will care when the JVM gets a single line of Kotlin commit.

Google should just buy JetBrains and rename ART into KVM.

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

#227

Post by Trasmatta » Thu, Feb 10, 2022, 8:10 PM UTC

YEwSdObPQT wrote: post #197

I am not a fan of these things. Much like big JavaScript frameworks whenever you need to do something outside of the mechanisms they provide things become very difficult very quickly and you still need to use JavaScript, HTML and CSS anyway as others have pointed out.

That's why I like StimulusReflex (and Hotwire). Stimulus offers a very nice pattern for adding the small bits of additional JS you need without ad-hoc JS spaghetti, while letting you push the vast majority of the rest to the backend.

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

#228

Post by skydhash » Thu, Feb 10, 2022, 8:13 PM UTC

rglover wrote: post #223

What's incredibly frustrating about the knocks on JavaScript is that it's not a shortcoming of the language that creates the problems hinted here, but the poorly-considered engineering choices of the popular frameworks. After building my own framework [1] last year, I realized just how disconnected JavaScript developers—yes, the "big boys" are especially off in CS la-la land—were from web development fundamentals. HT…

Most languages are quite tough to get into. And they require some real learning if you want to do anything trivial. JS is easy to get started (only the browser you already have) and you can do quite a lot without understanding anything about computer science. But it catches to you anyway. I've seen on Twitter someone repelled by the MDN documentation, describing it as not intuitive. I realized that the documentation assumes you're familiar with the basic tenets of programming (data types and structures, function signatures, ...). Which bootcamps often conveniently ignore.

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

#229

Post by Toine » Thu, Feb 10, 2022, 8:24 PM UTC

brtkdotse wrote: post #182

I couldn’t care less about the actual language. What I do care about is not having to maintain two separate tool chains and package managers, one for backend and one for front end.

Doesn't NextJS solve this ?

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

#230

Post by pphysch » Thu, Feb 10, 2022, 8:25 PM UTC

rglover wrote: post #223

What's incredibly frustrating about the knocks on JavaScript is that it's not a shortcoming of the language that creates the problems hinted here, but the poorly-considered engineering choices of the popular frameworks. After building my own framework [1] last year, I realized just how disconnected JavaScript developers—yes, the "big boys" are especially off in CS la-la land—were from web development fundamentals. HT…

> Though, not surprising, when you realize a lot of the momentum in JavaScript the last decade or so was perpetuated by venture capital (and the inevitable fast and cheap nature of that world) being pumped into inexperienced teams.

Yep. Frontend frameworks get you a slick looking responsive GUI with not much effort (you are outsourcing most of the design work). This wows the average VC. The VC funds you rather than the team with an architecturally simple frontend, and the framework flywheel gains momentum.