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

301–310 of 328 posts

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

#301

Post by jillesvangurp »

deckard1 wrote: post #275
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…

> Browser side Javascript is just a compiler target at this point you're a decade late to this observation. CoffeeScript came out around 2009. The world has largely been transpiling to ES5 for at least eight years now. The fact of the matter is, JavaScript post-ES6 is a solid language. Many of those people that were using ClojureScript/CoffeeScript/etc. have moved back to JS. 2007 JavaScript has almost nothing in com…

Accessibile UIs are possible outside the browser as well. Lots of native applications exist that are accessible by e.g. blind people. Actually a lot of that stuff existed before the web was even a thing. All that stuff can now be compiled to run in a browser.

The majority will continue to follow the easiest path. Which is not necessarily JS+DOM+CSS anymore. And contrary to your point, there always was a lot of friction with flash and Java or other plugins like silverlight. You had to install them, you had to keep them updated, they had security and performance issues, etc.

General design by committee browser standards are kind of very limiting however. It doesn't even come close to what was possible 15 years ago with flash and shockwave. That's why games don't have browser based UIs for example. They suck. It's just not good enough if you are trying to immerse the user in a futuristic and playful game world. That's also why mobile phones have native UIs. We can do better than dom+css. Way better. And now that we no longer have to stick to just ccs+dom in a browser, inevitably people are going to make use of that.

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

#302

Post by jillesvangurp »

udbhavs wrote: post #117
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…

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

Mostly good. We use the Fritz2 framework. It's a reactive UI framework that has a nice component library and supports styled components using a Kotlin DSL for CSS. It heavily leans on things like Flows (from Kotlin's co-routines library). We have a multiplatform client library that uses kotlinx-serialization, ktor, kotlinx-date, and a few other things.

Interoperability with javascript is possible but a bit cumbersome due to the need to map types. A typescript mapping conversion exist but it does not really work that well. We use e.g. the maplibre framework to display maps and it has issues converting the type mappings for those. We ended up doing this manually for the bits of API we needed.

Main downsides are the relatively immature tooling (though that has rapidly improved over the last year) and slowish build speeds. The Kotlin compiler has some performance issues.

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

#303

Post by jamil7 »

giantrobot wrote: post #287
mavelikara wrote: post #233

Earlier quoted context omitted.

> 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. Can you please elaborate what these areas of disconnect are? I looked at Joystick documentation hoping to find more of your thoughts this topic, but…

> Can you please elaborate what these areas of disconnect are? I'm not the OP but something I have noticed is the JavaScript wünderkind seem to want to completely reinvent web browsers but in JavaScript. They seem to not actually know HTML, CSS fundamentals, or even HTTP. So you end up with frameworks that reinvent everything a browser already gives you (for free) but entirely inside their JavaScript monstrosities. I…

It’s worse than that, not just web browsers, they’re also forcing these frameworks into desktop apps, mobile and embedded because they refuse to learn any other platform or language.

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

#304

Post by minusf »

9935c101ab17a66 wrote: post #289
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…

You say that JSX adds complexity and plain HTMl is simple and obvious, and yet, when I look at joystick, I see a render functions, and non-obvious helpers like `each, when, component`, etc. JSX is really simple to understand for basic use cases and it provides so many benefits: - support for Javascript expressions - transpilation - better error reporting I'd also argue that JSX is overall a LOT more readable than som…

readability is subjective, ymmv.

jsx makes my eyes bleed, it's like php4 in js, and it's full of corner cases you could never guess without cheatsheets and round trips to the docs.

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

#305

Post by tie_ »

jjtheblunt wrote: post #252
tie_ wrote: post #136

Earlier quoted context omitted.

I'm happily using Phoenix+LiveView for a website that works as a PWA. This also includes offline mode with sync-when-internet-is-available functionality (thanks PouchDB!). This covers online/offline/mobile usecases, with no explicit RPC, and no requirements for the end device that the app would run on, other than a _capable_ browser. (Admittedly, browsers on iOS are gimped, but that's part of the Apple tax).

what is gimped about iOS browsers?

WebPush is the feature that I'm missing. See https://developer.apple.com/forums/thread/114503

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

#306

Post by tie_ »

ngrilly wrote: post #267
tie_ wrote: post #136

Earlier quoted context omitted.

I'm happily using Phoenix+LiveView for a website that works as a PWA. This also includes offline mode with sync-when-internet-is-available functionality (thanks PouchDB!). This covers online/offline/mobile usecases, with no explicit RPC, and no requirements for the end device that the app would run on, other than a _capable_ browser. (Admittedly, browsers on iOS are gimped, but that's part of the Apple tax).

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.

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

#307

Post by aej »

vasergen wrote: post #218
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…

out of curiousity, how difficult to support large project in elixir, especially refactoring, giving there is no static typing. I know about pattern matching, which helps, but interesting to hear practical experiance

When it comes to refactoring, the fact that Elixir is compiled helps a lot - there are a set of mistakes you make during a refactor which the compiler will just catch for you.

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

#309

Post by antifa »

josephg wrote: post #294
unleashit wrote: post #285

Earlier quoted context omitted.

I love how the new Reddit gets frequently used as a straw man in arguments of front end developers are bad, the state of front end is a mess, etc. If you care to look at the actual reasons that Reddit and so many modern websites really are terrible, you'll see that it comes from the top and in many cases is on purpose. Reddit (and many others) don't want you to use their website. Especially on a mobile browser. They…

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

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

#310

Post by AprilArcus »

addaon wrote: post #272
AprilArcus wrote: post #195

Earlier quoted context omitted.

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

Isn't front end software almost defined by latency sensitivity, though? It seems that after logical correctness, there's nothing more important for user experience than bounded and low latency.

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