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

191–200 of 328 posts

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

#191

Post by yawaramin »

ivanmontillam wrote: post #47

I've been looking for this for a long while. I am surprised that there are no browsers that can support other languages. My ideal architecture is to have a browser where you can select your front-end language interpreter, as in a Chromium + V8 + CPython + Whatever front-end processor you might want (Brython[0] achieves this, but transpiling to JavaScript). What doesn't make sense to me is that JavaScript has genuinel…

That's actually not what the article is about. It's more about the backend server managing all or most of the application state, and sending slices of JSON or even fully-rendered HTML to the browser, which is responsible only for swapping in these new slices of UI with a thin layer of JavaScript.

In other words, it's about creating a SPA-like experience with little or no custom-written JavaScript.

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

#192

Post by _xnmw »

kuon wrote: 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…

> Having the full client state available on the backend is really incredible.

Got the exact same feeling writing my latest app with Laravel Livewire. The ability to use backend state seamlessly on the frontend without explicitly passing state back and forth reduces complexity so much it's like writing 1 application instead of 2. I was able to build rich, fully interactive apps with minimal JS -- I'll never go back to React again.

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

#193

Post by zo1 »

axiosgunnar wrote: post #173
hnfong wrote: 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.

> The side that insists on using strongly typed languages for a weekend throwaway project? yes? it's gonna take me 30min in a dynamic language because i keep running into "undefined" errors, or 20min in a strongly typed language because if the IDE is happy, i know it will work. the advantage of strongly typed languages is linear, from something that takes 10 minutes to something that takes 10 years, coding in a stron…

And don't forget the 15mins you spent choosing how to handle multiple types and future proofing by adding IOC and a DI framework that works like magic. Oh and the myriad activations and config that library devs added to their frameworks using a Fluent syntax because it looks better. No thanks.

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

#194

Post by monocasa »

cies wrote: post #124
jillesvangurp wrote: post #112

Earlier quoted context omitted.

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…

> Long term WASM is a more efficient compiler target. Smaller, faster, easier to deal with for compiler builders, etc. And more obfuscatable.

I'd say obfuscated JavaScript is more obfuscated than stripped Wasm. In cases where you don't have meaningful symbol names either way, wasm's code flow is required to be significantly more structured than what you can get a JavaScript VM to accept and run. Those invariants that help the VM make sure the code is safe to run at close to native speed also halos automated tooling deobfuscate it.

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

#195

Post by AprilArcus »

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…

> the second group has managed to compile more-and-more of it's langs to JS and WASM

The second group is incentivized to do so, because they still have value to bring.

JavaScript 2022 has sucked all the air out of the room in terms of dynamic dispatch, untyped PLs. Compared to Python, Ruby, and Lua, it has better startup time and throughput, and at the end of seven years of pilfering every good idea any of those languages ever had* (and a few bad ones**), it is by now equally or more expressive by every metric. It's also the most popular PL in history, with a variety of maintained and opinionated libraries for every conceivable task.

Given that JavaScript is already the ultimate flavor Objective-Blub, it makes no sense to write a JS-targeting transpiler for your favorite minor flavor of Blub. And since you're already targeting a browser, Lua's embedability and Python's C FFI are no advantages. The only remaining language in this family with interesting features that JavaScript hasn't (and may never) co-opt is Racket, with its powerful hygienic macros.

To a lesser extent, this is also becoming true for the statically typed languages, where TypeScript*** offers a better developer experience than, and has made significant inroads against the faster but similarly expressive SML/OCaml/F#/Bucklescript/Reason/ReScript family (to say nothing of Java!).

On the other hand, the camp of "I prefer to use strong typing and proofs to ensure it does not break at runtime" still has concrete advantages to bring to the world of FE dev, namely:

  • Non-GC memory management strategies suitable for latency sensitive applications (C, C++, Rust)
  • Static member lookup & method dispatch (C++, Rust)
  • SIMD (Rust)
  • Higher-kinded types (Haskell, PureScript)
* block scope, destructuring assignment, default parameters, safe navigation, modules, iterators, generators, async/await, template strings, regexp named matches and lookarounds, BigInts

** classes

*** While TypeScript is technically a compile-to-JS language, it is such a thin layer on top of JS that there is essentially no impedance mismatch between TS in an IDE and interactive debugging, which makes it unique within that category.

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

#196

Post by tluyben2 »

gregors wrote: post #178
rafale wrote: post #91

Earlier quoted context omitted.

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.

I'll politely disagree with you and illustrate the many many many unicorns that were brought into existence under dynamic languages. And places such as Shopify which are after-the-fact adding typing to previously untyped languages. Every single bug that has ever existed in static languages passed the type-checker. There are benefits in types to be sure but cornering the market on "growing and lasting" is definitely n…

So you launch and the you add (dependent) types. That works and is quite a good way imho: when you start writing you miss a lot of details so you want to freely experiment and when parts get clearer and become stable you can rewrite, reactor, add types and proofs.

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

#197

Post by YEwSdObPQT »

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.

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

#198

Post by crnkofe »

deepsun wrote: post #71

I remember JSF (Java Server Faces) and GWT (Google Web Toolkit). Both burned in flames. JSF: main idea is to abstract away boundary between server and client. Turns out -- you really want to know where that thing is running -- on the server or on the client. So it turned into a fight against that main idea of JSF. GWT: main idea is to forget JavaScript/DOM and write pure Java. Turns out -- you really need to know Jav…

I've worked quite a bit with JSF and although I was never a fan it does have some points. It allows for focusing more on contents than visuals also assuming the visuals won't be that fancy. There's plenty of apps that don't really require going all-out on eye candy. Note that it was always a problem when people do want eye candy. I also rarely had issues with performance but perf. is always an issue regardless of working with server- or client-side rendering.

I pray for WASM to eventually replace JS. NodeJS ecosystem with all the experimental features, job ads in update notes, shitload of dependencies, one-function packages, legacy JS is a special kind of pain that I avoid whenever I can.

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

#199

Post by randito »

rashkov wrote: post #60

Can anyone clarify what this quote refers to: "what really sets Erlang apart, for McCord, is its ability to preschedule processes so that the CPU doesn't get hung up on any single thread." What's this concept called? Is it simply a matter of setting a priority level on a certain task, that way the scheduler can make sure it doesn't block?

If you want to see a really nice demo of this, check out https://www.youtube.com/watch?v=JvBT4XBdoUE -- The Soul of Erlang and Elixir by Saša Jurić.

There's a really neat demo of a machine at 100 CPU% but that's still responsive because of Erlang's preemptive scheduling. There's a ton of other goodies in that video if you're interested.

It really shows off the Erlang BEAM VM.

Post reply on HN