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

131–140 of 328 posts

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

#131

Post by jayd16 »

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…

It seems like a silly point to make considering the actual content of the article.

It's talking about server-side rendering. While the title might be a little provocative, its certainly talking about rendering UI (the front end) using whatever language you used on the back end, even if it was JS.

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

#133

Post by smasher164 »

cies wrote: post #129
Zababa wrote: post #81

Earlier quoted context omitted.

> 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". I think the opposite, the rift has been healing. It seemed that it was pretty big in the 2010's (Python/Ruby/Perl vs Java/C#/C++) but these days we have TypeScript, Rust, Kotlin; Java and C# are getting better t…

> healing > these days we have TypeScript, Rust, Kotlin; Java and C# are getting better too (type inference), Python and Ruby are getting typechecking everyone caves to the types. i think the strongest holdout is probably the LISP/Clojure corner. they have optional typing for along time, but it is not used that much afaik many have voiced their reasons for liking dynamic typing. i only have one: faster reload cycles…

It's a false dichotomy. If you defer type-checking to runtime, you have a traditional dynamically typed language. Haskell has this in the form of -fdefer-type-errors, but I'd like to see this feature given more emphasis and used in other languages.

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

#134

Post by KwisaksHaderach »

samhw wrote: post #128
jvanderbot wrote: post #127

Earlier quoted context omitted.

That is impressive, and not unexpected given the (likely) billions of dollars of investment in things like nodejs. I did not mean to disparage it in itself just because it was developed for a particular domain. However, if "An embedded system uses the internet to communicate" has become synonymous with "It runs linux and uses web services and nodejs" then that would be a perfect example of contorting the application…

> I did not mean to disparage it just because it was developed for a particular domain. Fair enough, that's all I was saying. I'd agree with you that the increased use of Node everywhere to build applications, with tools like Electron, is an utterly stultifying trend. It's fantastic for I/O-heavy 'server'-type code, and for using JS as an at least surprisingly performant interpreted language, but it's disappointing t…

It's fantastic for I/O-heavy 'server'-type code

I have found nodejs frustrating for CRUD APIs, the is 'fantastic for heavy I/O' while true ends up guiding you to complex microservices(or trying to use a external services for everything) because you don't want to slow down the event loop as you add more and more cpu processing to your app.

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

#135

Post by mrtksn »

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…

JavaScript itself is very powerful in its own domain(the DOM interactions in the browser) but most of the bloat comes from developers wanting to write JS in different way than originally designed. 20 years of JS frameworks and at the end of the day all they do is arranging HTML boxes through slightly different code.

But why so many frameworks for the exact same output? It usually comes down to code management and making the code writing closer to the mental models of the problem they intend to solve.

I find it very unproductive to try to force JS to fit in every domain possible because there are already very mature languages who were designed with that domain in mind. That said, JavaScript has the power of being able to run everywhere which gives it unique advantage in actually learning and running the code written in JS.

I don't have a conclusion for this. I know JS and feels great to be able to run it everywhere, especially quick and dirty solutions are almost as nice as working with PHP. However, it easily frustrates me when trying to do something better than quick and dirty and start appreciating the domain specific toolsets. I guess the moral of the story is that JS is great but let's not try to solve every problem with it.

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

#136

Post by tie_ »

lucasyvas wrote: post #25

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…

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

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

#137

Post by cies »

smasher164 wrote: post #133
cies wrote: post #129

Earlier quoted context omitted.

> healing > these days we have TypeScript, Rust, Kotlin; Java and C# are getting better too (type inference), Python and Ruby are getting typechecking everyone caves to the types. i think the strongest holdout is probably the LISP/Clojure corner. they have optional typing for along time, but it is not used that much afaik many have voiced their reasons for liking dynamic typing. i only have one: faster reload cycles…

It's a false dichotomy. If you defer type-checking to runtime, you have a traditional dynamically typed language. Haskell has this in the form of -fdefer-type-errors, but I'd like to see this feature given more emphasis and used in other languages.

I've not seen it work (not in Haskell, not in other strong typed langs). Java with IntelliJ does quite well, but then it is VM based and not very strongly typed. Kotlin has a much better type system, but then compile times start to become much more noticeable as well.

In heard OCaml has a quick reloads in some scenarios, but I never tried.

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

#138

Post by ledgerdev »

girvo wrote: post #5

Funnily enough, PHP (like, old school PHP) is a surprisingly neat fit for this style of programming when combined with htmx[0] Tiny amount of glue HTML attributes, a heap of partials that are your PHP files and you’re good to go. What is old is new again I suppose: we used to do this with PHP and jQuery once upon a time too — though LiveView and similar are far nicer of course. I’ve been working on some personal tool…

So, I have only been working in htmx for about a week on a multi step checkout app, and while it's been mostly awesome, I think I ran into the Achilles heel of htmx, form state and the back button.

In short of you enter data into a form then htmx push navigate away, when you click the browser back button you get the dom as it was originally delivered from the server, without any data the user might have entered into text boxes. This is a show stopper problem and been working on work arounds, not sure any is good. Basically we have resorted to plain old full page reloads with client side redirect to resolve this.

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

#140

Post by KwisaksHaderach »

cies wrote: post #137
smasher164 wrote: post #133

Earlier quoted context omitted.

It's a false dichotomy. If you defer type-checking to runtime, you have a traditional dynamically typed language. Haskell has this in the form of -fdefer-type-errors, but I'd like to see this feature given more emphasis and used in other languages.

I've not seen it work (not in Haskell, not in other strong typed langs). Java with IntelliJ does quite well, but then it is VM based and not very strongly typed. Kotlin has a much better type system, but then compile times start to become much more noticeable as well. In heard OCaml has a quick reloads in some scenarios, but I never tried.

You are looking for Golang ;)
Post reply on HN