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

321–328 of 328 posts

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

#321

Post by fshr »

lxe wrote: post #260
dnautics wrote: post #59

Chris McCord, quoted in the article, explains extremely well the absurd state of stateless http requests, from a perspective that is not appreciated in the article (queued to 40m50s): https://www.youtube.com/watch?v=XhNv1ikZNLs&list=PLqj39LCvnO... The programming model (in liveview, don't know about blazor or hotwire or livewire) really lets you get better performance by doing less. A part of me sarcastically thinks…

He just glosses over the "you can use a websocket API", which would solve most of the issues he's describing. There are a ton of websocket libraries that are easy to use. Do all the auth and session establishment once, and then communicate over websocket if you hate sending cookies and session data back and forth.

No, you missed the point. Liveview works because there’s a stateful Elixir process on the backend for each open ws connection. This model doesn’t work in nearly any other backend option in any other language. If he glossed over the web socket option you’re glossing over the uselessness of the ws if the backend has the memory of a goldfish.

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

#322

Post by josephg »

antifa wrote: post #309
josephg wrote: post #294

Earlier quoted context omitted.

We might have to agree to disagree on this. I bet a huge percentage of Reddit’s traffic comes from their website. And if they didn’t want people using the website, they wouldn’t have bothered putting so much effort and attention into the redesign. Why bother redesigning something you want nobody to use anyway? And if your argument is that they made it bad on purpose, they may as well have just made their old site wor…

The redesign was for showing more ads, not for users to enjoy and want to come back

I'm obviously not convinced. Do you have anything more solid than pure conjecture?

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

#323

Post by pjmlp »

BoorishBears wrote: post #320
pjmlp wrote: post #226

Earlier quoted context omitted.

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.

This is being too charitable to Java imo, after all we had stuff like Retrolambda at the time. Kotlin exists because Java moved like molasses for years If Java had moved like C# it'd be a much nicer language today, and Kotlin wouldn't be needed. Even comparing Kotlin 1.0 to today's Java nearly 6 years later would favor Kotlin for ergonomics with stdlib, nullability, reified generics, and syntax

Retrolambda, yet another kludge, instead of invokedynamic calls.

Kotlin exists because JetBrains wants your money, that is all.

> The next thing is also fairly straightforward: we expect Kotlin to drive the sales of IntelliJ IDEA. We’re working on a new language, but we do not plan to replace the entire ecosystem of libraries that have been built for the JVM. So you’re likely to keep using Spring and Hibernate, or other similar frameworks, in your projects built with Kotlin. And while the development tools for Kotlin itself are going to be free and open-source, the support for the enterprise development frameworks and tools will remain part of IntelliJ IDEA Ultimate, the commercial version of the IDE. And of course the framework support will be fully integrated with Kotlin.

https://blog.jetbrains.com/kotlin/2011/08/why-jetbrains-need...

Outside Android, I will care about Kotlin when KVM becomes an unavoidable reality, until then, it can party with Beanshell, jTCL, Jython, JRuby, Scala. Closjure, Groovy, Frege, and plenty of other ones,

https://en.m.wikipedia.org/wiki/List_of_JVM_languages

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

#324

Post by 2ion »

lpghatguy wrote: post #246
2ion wrote: post #184

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.

C++ is not nearly as productive a language for most programmers in the world as JavaScript. Qt is not a panacea, even for desktop apps. The condescending tone to web developers is very strange and not very nice.

> Qt is not a panacea, even for desktop apps

My point is: all achievements in web dev modularity and features have been present in Visual Basic, Delphi, TurboC++, Java and Qt since the early 2000s. Fully hardware accelerated UIs to boot. Well, we decided to move it all into the browser sandbox and start from scratch. Tools like QtCreator or the VisualBasic form editor got replaced by an expensive toolchain ranging from Adobe products to 1000 npm packages.

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

#325

Post by ngrilly »

tie_ wrote: post #306
ngrilly wrote: post #267

Earlier quoted context omitted.

I don’t understand. How is the app working in offline mode when the Phoenix server is not reachable, since the interactions are managed server-side with LiveView?

Sorry, my statement indeed got confusing. I'm using LiveView for online interactions. I'm using PouchDB + JS for data synchronization and enabling offline work. You are right that LiveView itself does need to be online, since it's whole point is to move (back) the UI logic to the server side.

Thanks for clarifying!

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

#326

Post by cestith »

chrismccord wrote: post #224
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 writ…

I think you're the only one to mention JSON or serialization at all. I do believe I already said websockets were the innovation, but they really literally did not exist 15 years ago for us to use. Elixir being distributed is nice. You still need the logic to get the change into everyone's session. You're just not using an external DB, cache layer, or work queue to do it.

It's amazing, really, how people feel comfortable condescending to others who explain how we did things before the current technologies existed as if we could never grasp how the new technologies improve things. Yes, this is nice, but it's evolutionary, not revolutionary.

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

#327

Post by fshr »

addaon wrote: post #319
AprilArcus wrote: post #310

Earlier quoted context omitted.

FE can tolerate 10-20 ms of timer slosh, unlike e.g. audio synthesis.

120Hz+ screens are becoming common place. For the first time in decades, this guidance is no longer true -- it's reasonable to design for a frame or so of fixed latency, but to avoid jitter the latency should really be bounded within 8 ms these days.

> 120Hz+ screens are becoming common place.

No they aren’t. The market share and purchasing incentive for the mainstream market are single percentage points.

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

#328

Post by ric2b »

throwthere wrote: post #263
rglover wrote: post #256

Earlier quoted context omitted.

I've tried writing a response to you a few times but realizing how complex it is—the real answer to your question is worthy of a long blog post. The core problem is the blurring of the lines between a framework and the underlying technologies of the web (HTML, CSS, and JavaScript). To me, it seemed like a lot of unnecessary complexity was being added just to achieve the common goal of rendering some HTML, styling it…

Every framework has its learning curve, tradeoffs and frustrations. JSX isn’t that far off from html and can be insanely productive for generating reactive UIs compared to the old jquery days. I’m not sure there’s a one true framework that is easy to learn, sticks to idealistic cs principals and is productive.

> I’m not sure there’s a one true framework that is easy to learn, sticks to idealistic cs principals and is productive.

Svelte, the tutorial is short and runs directly in your browser: https://svelte.dev/tutorial/basics

Post reply on HN