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

201–210 of 328 posts

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

#201

Post by whynaut »

Supermancho wrote: post #185
RussianCow wrote: post #165

Earlier quoted context omitted.

This is wrong; tests and type systems have different purposes. One helps prevent logical bugs and regressions in your code, while the other enforces the correct use of code and data structures. They overlap a bit, but all the unit tests in the world can’t give you the guarantees that a type system does. And that’s without even mentioning the benefits to discoverability and documentation that a static type system give…

> This is wrong; tests and type systems have different purposes. For decades, companies have prospered without a strong type system and using tests for type assurance ad hoc. Usually when it's worrisome or has been problematic. You can say it's wrong (conceptually, theoretically, etc) and yet it people continue to do it. That's interesting to think about.

don't think it matters since the upthread discussion is more about understanding and refactoring code, not ensuring correctness.

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

#202

Post by [deleted] »

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.

[deleted]

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

#203

Post by marwis »

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…

Also Vaadin which sort of combines two approaches and these days even allows you to go Java-only or Javascript-only. The company is still alive and well so I assume it's popular for internal enterprise apps.

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

#205

Post by jordanab »

ducharmdev wrote: post #76
thrower123 wrote: post #16

Earlier quoted context omitted.

I do dearly hope Blazor works out - I would be so happy to never have to deal with the Javascript/Typescript tooling hell ever again - but I'm not holding my breath. Political shifts inside Microsoft could leave it dead and unsupported like Silverlight tomorrow...

Compared to the Blazor tooling, the Typescript tooling is miles ahead imo. We did a Blazor app during a hackathon and I was pretty frustrated with how inconsistent the build errors were with blazor components. What makes me most skeptical about Blazor though, is that it's shifting a huge burden to the client just to make developers happy. Even if the runtime is stripped down and compiled to wasm, it seems kinda wild…

I'm already seeing a lot of enterprise companies gearing-up to go all-in on Blazor. Having a single language (C#) for web, mobile and all other back-end services must be huge draw for them.

> What's funnier too, is that it's been possible to write F# on the frontend for a while now, compiling down to javascript (like clojurescript). It makes me wonder why this approach was never done with C# too, even if there are pitfalls in compiling to javascript.

There have been several initiatives which allowed you to do that. None of them really successful. I've worked with one specifically in the past (can't remember the project's name though), which even had C# types/bindings for Knockout.js.

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

#206

Post by [deleted] »

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…

[deleted]

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

#207

Post by derekzhouzhen »

There are 3 different kinds of web applications:

* smart front end, dumb back end. This is the SPA model * dumb front end, smart back end. This is the old school model * smart front end, smart back end. This is the new school model

If you can get away with the SPA model, by all means do it. Liveview is not going to challenge that. What it is doing, is to give new live to the old school model so you can avoid the complexity of having both a smart front end and a smart back end for a large percentage of applications. A smart/smart system is an asymmetric distributed system, a beast to handle for gurus and novices and everyone in between.

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

#208

Post by monocasa »

zo1 wrote: post #193
axiosgunnar wrote: post #173

Earlier quoted context omitted.

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

That's orthogonal to strong types. Java isn't the pinnacle of what strong type systems can look like.

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

#209

Post by cies »

AprilArcus wrote: post #195
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 lang…

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

exactly.

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

#210

Post by cies »

KwisaksHaderach wrote: post #140
cies wrote: post #137

Earlier quoted context omitted.

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

You are right. I have no experience with Go, but that's a fast compiler for sure.

Though they miss out heavily in the typing strength. If only it had Result/Either/Maybe types in the std lib from day 1, and proper sum types with some pattern matching switch statement, that would have made the language soooooo much better.

I find Elm also has good compile times. Maybe polymorphism and/or type-classes are what is hard to optimize.

Post reply on HN