Live data from Hacker News

Back-end languages are coming to the front-end

github.com

171–180 of 328 posts

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

#171

Earlier quoted context omitted.

I'm really sad that Dart didn't make it as Javascript replacement. It's much better designed language, but didn't get traction.

Dart is not fhat much better. In a period where most languages are experiencing a "rebirth" as a well thought out modern language , Dart feels like the "before" waiting for an "after". I'd be deeply disappointed if we had progressed from Js to Dart, and it's why I'm not a fan of Flutter (Java => Kotlin, Obj C => Swift, Js => Ts, Erlang => Elixr, etc.)

> Java => Kotlin,

If you are speaking of Android, yes.

On the JVM is it just one more guest on the building.

https://madnight.github.io/githut/#/pull_requests/2021/4

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

#172

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

"Political shifts inside Microsoft could leave it dead and unsupported like Silverlight tomorrow" Assumption or knowledge? How do you know this?

Experience, many of us have been on the PC platform since the MS-DOS, and have seen how Microsoft politics play out, killing cool technologies because politics.

Hence the famous xckd comic.

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

#173
post #93
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.

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 strongly typed language is always X% faster.

put the other way: why would I want to code in a language that allows me to write impossible code? what is the point?

the only selling point of python is the large corpus of third party packages (numpy etc), and that the syntax "looks simple" and is thus beginner-friendly.

there is literally no other reason to use it apart from the above two reasons.

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

#174

Earlier quoted context omitted.

"Political shifts inside Microsoft could leave it dead and unsupported like Silverlight tomorrow" Assumption or knowledge? How do you know this?

I've seen the cycle too many times over the past decade or so. It's really bad with the various desktop UI frameworks, but it happens with most everything they put out. If something doesn't get immediate traction, and doesn't have strong champions inside of Microsoft, things all too often wither on the vine and go by the board. Big bang initial rollout coinciding with Build, showing off some fancy capabilities that n…

Even when they have strong champions, if they get distracted, the opposition is quite quick to move in.

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

#175
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…

A question from a newcomer to the ecosystem: do you have any recommendations for an admin system like Django's? On a related note, how do you usually determine whether a package is abandoned vs stable?

The crazy thing is that most elixir packages that are abandoned still basically work. This is both a blessing and a curse all around

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

#177
post #116

Have I interpret well? It's like a kind of virtual dom put on server-side? What a bad idea, please don't do it!

In an abstract sense, yes, but we don't actually keep a vdom in Phoenix LiveView. You might want to reconsider this hot take. We actually send less data on the wire than the best hand-written JSON payload you could come up with in many cases. If you're curious how that works, I have a pretty detailed write up on it that may change your mind: https://fly.io/blog/how-we-got-to-liveview/

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

#178
post #91
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 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 not one of them. If anything I'd say types let you refactor quicker - dynamic languages let you launch faster.

I should also note that I don't mean dependent type languages which I haven't actually shipped anything professionally but I'm extremely curious about.

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

#179
post #158
post #145

Earlier quoted context omitted.

> NodeJS relies on V8, which is perhaps the world's most highly optimised interpreter (/JIT compiler/runner), and a spectacular piece of software. Uhm, has V8 come anywhere near LuaJIT's performance by now? And LuaJIT is basically a one-man effort.

Sorry, I should have been clearer: I meant that it's had the most manpower dedicated to optimising it, not that it's necessarily the most optimal . It's hard to make apples-to-apples comparisons in that respect, given the significant differences between different language specifications. (For instance, it's hard for anyone to write a reference-compliant interpreter for Python which is as fast as the interpreter they…

Well you did say: “ NodeJS relies on V8, which is perhaps the world's most highly optimised interpreter (/JIT compiler/runner)”

But even in manpower this is pretty hyperbolic compared to Java and .NET. There was probably more manpower in even some of the third party Java runtimes like Azul.

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

#180

When is the world of software going to wake up? All programming languages suck, in one way or another. All frontend/backend paradigms suck, in one way or another. This constant churn of new, new, new is a waste. It gets replaced every few years, meaning all the time, effort and money sucked into it is gone. And engineers re-learn the same lessons over, and over, and over again. All so software engineers can be happy,…

After having been in this industry for 20+ years, I can pretty confidently say the world of software will never wake up. It's just been an endless cycle of adding abstractions, removing them again, using back end languages on the front end, using front end languages on the back end, using relational databases instead of a key value store, using key value stores instead of a relational database, unit tests over integr…

Same here.

I think the fashion industry is a consequence that a big subset of the industry lives from selling services, books, trainings, conference talks,....

So the need for something new needs to be constantly generated so that the crowds feel the need for new content and buying services.

Then on top of that, most people new to the industry tend not to learn the past, so they keep re-discovering stuff as the "new coolness".

Post reply on HN