9 ms·

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 n

by cies 5y ago

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 group has managed to compile more-and-more of it's langs to JS and WASM.

Zababa 5y ago
> 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 too (type inference), Python and Ruby are getting typechecking.
- cies 5y ago
  > 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 while developing. the other pros of dynamic typing are all over shadowed by their inherent downsides.
  - smasher164 5y ago
    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.
    - cies 5y ago
      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.
      - KwisaksHaderach 5y ago
        You are looking for Golang ;)
        cies 5y ago
        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.
  - Zababa 5y ago
    > everyone caves to the types. In a way, but static languages have also heavily invested in ergonomics. Type inference is the best example I think. On the other hand, there are also other stuff like immutability that's getting popular in both languages. It seems like 10 years before you had to choose between developing software fast and developing reliable software, these days it's easier to have both.
rafale 5y ago
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.
- hnfong 5y ago
  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.
  - kevinmgranger 5y ago
    Indeed. Every single technical choice has tradeoffs. It's just that some tradeoffs are non-issues for narrow use cases.
  - rafale 5y ago
    "in any project that's meant to grow and last" I specified what I am talking about. Weekend projects are not even a contention point. People code them in Brainfuck and we all have a laugh about it. It's the stuff that end up at the job that frustrate us where you end up assigned to a 100k (or even just 10k) lines of javascript inferno hell. Because some dev thought he can develop "faster" in Javascript.
    - Tade0 5y ago
      Adequate testing goes a long way in dealing with that. If you don't have tests you're screwed either way.
      - RussianCow 5y ago
        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 gives you.
jvanderbot 5y ago
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 seeing precisely the kind of domain crossover TFA hints at. Somehow, since Rust is cool, it should be the future of web / in-browser[1]. Somehow, since JS is popular and easy to use, it should be on the james web space telescope[2]. Somehow, since browsers are well accepted, node.js is a reasonable benchmark for embedded systems performance [3] GTFO with that. That is how we get language bloat and the many overlapping frameworks that creep into the language and make it unrecognizable. I'm looking at you, Tokio and D3. 1. https://leerob.io/blog/rust https://leerob.io/blog/rust 2. https://old.reddit.com/r/programming/comments/bglvey/the_9bn_james_webb_space_telescope_will_run/ https://old.reddit.com/r/programming/comments/bglvey/the_9bn... 3. https://jaycarlson.net/embedded-linux/ https://jaycarlson.net/embedded-linux/
- samhw 5y ago
  > Somehow, since browsers are well accepted, node.js is a reasonable benchmark for embedded systems performance [3] NodeJS relies on V8, which is perhaps the world's most highly optimised interpreter (/JIT compiler/runner), and a spectacular piece of software. The v8.dev blog alone is fantastic reading for anyone who works on compilers, as I do. I don't like the 'dev' tendency in the programming community, to just hack stuff together and say "well, it works!", but I'm also not impressed by people trashing any high-level languages just because it's a meme they heard. V8 is phenomenally performant and is a hard benchmark to beat for anyone and anything, even at the compiled end of the spectrum. (Yes, it's beaten by C/C++/Rust/Go, but it's not to be sneered at, at all.) I'm struggling to equal it with the highly optimised Python JIT-assisted interpreter I'm writing for my work - even after relaxing the ABI and writing sophisticated instruction-set-specific optimisations. (And I'm writing it in Rust, just to score at least one point off the cargo-cult bingo card.)
  - jvanderbot 5y ago
jillesvangurp 5y ago
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 that, but "native" javascript just stopped being a mainstream thing quite a few years ago. That doesn't mean Javascript will go away but it does mean it now has to compete on merit rather than relying on it's status as the only thing that you can actually use in a browser. Many projects have already shifted to using Typescript for example. And from there to other transpiled languages is not that big of a leap. We use Kotlin-js for example. It's great. Other people use clojure, vue, elm or other languages that basically aren't javascript but that just happen to transpile to it. Long term WASM is a more efficient compiler target. Smaller, faster, easier to deal with for compiler builders, etc. The only remaining reasons to target browser js with your compiler, is that it still has better bindings to the browser APIs. This is something that is being worked on and of course that is more than offset by being able to compile existing libraries to WASM. WASM has a few other things as well that are still being worked on (threading, memory management/garbage collections, etc.). But long term, anything that javascript can do in a browser would be something you could do from a WASM compiled program as well. Once that works well enough, a lot more languages will start targeting browser applications just because they can. And a lot of developers that don't necessarily care about downgrading to Javascript might have a go at doing some applications that run in a browser. I predict a little renaissance in frameworks and tooling for this. And of course with WebGL and Canvas, using the DOM and CSS is entirely optional. For example Figma has a nice UI that looks like it would be hard to match with anything DOM based. They have a bit of react on the side for the bits that don't really matter but most of the app is C++. People also run games, virtual machines, etc. in browsers. There might still be valid reasons to use DOM + CSS like we have been for the last two decades. But it won't be the only choice for doing UIs. And being limited by it like we have been is increasingly no longer necessary either.
- udbhavs 5y ago
  Could you share some more about your experience with Kotlin js and the libraries/frameworks you use?
jayd16 5y ago
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.
jeremyjh 5y ago
Did you read the article or just the headline?
- cies 5y ago
  just the headline
tormeh 5y ago
> "I prefer to use strong typing and proofs to ensure it does not break at runtime" This has not been my experience with C++ (segfaults etc.) or Java (runtime introspection and exceptions). In ye olde languages compilation seems to be mostly (more than 50%) motivated by performance rather than correctness. Compiled languages have been doing steadily more compile-time work and improving ergonomics lately.
serverholic 5y ago
That rift has existed for a long time. There are some programmers who don't really care what tools they use as long as they feel productive. They shy away from things like types because it feels like it slows them down. Then there are programmers who care a lot about tools because it feels like the wrong tools hold them back and cause undue stress in the long-term. Hot take: The first type are less mature programmers :)
- deleted 5y ago
  [deleted]
- erik_seaberg 5y ago
  I do think some people feel productive writing more code, while others feel productive by finding ways to write less code (with the compiler mostly inferring and generating the error-prone and uncreative work).
- deckard1 5y ago
  > There are some programmers who don't really care what tools they use as long as they feel productive. They shy away from things like types because it feels like it slows them down. Right. The group that came up with the concept of a REPL and live in Emacs doesn't care about tools.
AprilArcus 5y ago
> 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 languages ever had* (and a few bad ones**), it is by now equally or more expressive by every metric. It's also the most popular PL in history, with a variety of maintained and opinionated libraries for every conceivable task. Given that JavaScript is already the ultimate flavor Objective-Blub, it makes no sense to write a JS-targeting transpiler for your favorite minor flavor of Blub. And since you're already targeting a browser, Lua's embedability and Python's C FFI are no advantages. The only remaining language in this family with interesting features that JavaScript hasn't (and may never) co-opt is Racket, with its powerful hygienic macros. To a lesser extent, this is also becoming true for the statically typed languages, where TypeScript*** offers a better developer experience than, and has made significant inroads against the faster but similarly expressive SML/OCaml/F#/Bucklescript/Reason/ReScript family (to say nothing of Java!). On the other hand, the camp of "I prefer to use strong typing and proofs to ensure it does not break at runtime" still has concrete advantages to bring to the world of FE dev, namely: • Non-GC memory management strategies suitable for latency sensitive applications (C, C++, Rust) • Static member lookup & method dispatch (C++, Rust) • SIMD (Rust) • Higher-kinded types (Haskell, PureScript) * block scope, destructuring assignment, default parameters, safe navigation, modules, iterators, generators, async/await, template strings, regexp named matches and lookarounds, BigInts ** classes *** While TypeScript is technically a compile-to-JS language, it is such a thin layer on top of JS that there is essentially no impedance mismatch between TS in an IDE and interactive debugging, which makes it unique within that category.
- cies 5y ago
  > The second group is incentivized to do so, because they still have value to bring. exactly.
- addaon 5y ago
  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.
deleted 5y ago
[deleted]

by cies 5y ago

Zababa 5y ago

> 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 too (type inference), Python and Ruby are getting typechecking.

cies 5y ago
> 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 while developing. the other pros of dynamic typing are all over shadowed by their inherent downsides.
- smasher164 5y ago
  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.
  - cies 5y ago
    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.
    - KwisaksHaderach 5y ago
      You are looking for Golang ;)
      - cies 5y ago
        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.
- Zababa 5y ago
  > everyone caves to the types. In a way, but static languages have also heavily invested in ergonomics. Type inference is the best example I think. On the other hand, there are also other stuff like immutability that's getting popular in both languages. It seems like 10 years before you had to choose between developing software fast and developing reliable software, these days it's easier to have both.

rafale 5y ago

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.

hnfong 5y ago
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.
- kevinmgranger 5y ago
  Indeed. Every single technical choice has tradeoffs. It's just that some tradeoffs are non-issues for narrow use cases.
- rafale 5y ago
  "in any project that's meant to grow and last" I specified what I am talking about. Weekend projects are not even a contention point. People code them in Brainfuck and we all have a laugh about it. It's the stuff that end up at the job that frustrate us where you end up assigned to a 100k (or even just 10k) lines of javascript inferno hell. Because some dev thought he can develop "faster" in Javascript.
  - Tade0 5y ago
    Adequate testing goes a long way in dealing with that. If you don't have tests you're screwed either way.
    - RussianCow 5y ago
      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 gives you.

jvanderbot 5y ago

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 seeing precisely the kind of domain crossover TFA hints at. Somehow, since Rust is cool, it should be the future of web / in-browser[1]. Somehow, since JS is popular and easy to use, it should be on the james web space telescope[2]. Somehow, since browsers are well accepted, node.js is a reasonable benchmark for embedded systems performance [3] GTFO with that. That is how we get language bloat and the many overlapping frameworks that creep into the language and make it unrecognizable. I'm looking at you, Tokio and D3. 1. https://leerob.io/blog/rust https://leerob.io/blog/rust 2. https://old.reddit.com/r/programming/comments/bglvey/the_9bn_james_webb_space_telescope_will_run/ https://old.reddit.com/r/programming/comments/bglvey/the_9bn... 3. https://jaycarlson.net/embedded-linux/ https://jaycarlson.net/embedded-linux/

samhw 5y ago
> Somehow, since browsers are well accepted, node.js is a reasonable benchmark for embedded systems performance [3] NodeJS relies on V8, which is perhaps the world's most highly optimised interpreter (/JIT compiler/runner), and a spectacular piece of software. The v8.dev blog alone is fantastic reading for anyone who works on compilers, as I do. I don't like the 'dev' tendency in the programming community, to just hack stuff together and say "well, it works!", but I'm also not impressed by people trashing any high-level languages just because it's a meme they heard. V8 is phenomenally performant and is a hard benchmark to beat for anyone and anything, even at the compiled end of the spectrum. (Yes, it's beaten by C/C++/Rust/Go, but it's not to be sneered at, at all.) I'm struggling to equal it with the highly optimised Python JIT-assisted interpreter I'm writing for my work - even after relaxing the ABI and writing sophisticated instruction-set-specific optimisations. (And I'm writing it in Rust, just to score at least one point off the cargo-cult bingo card.)
- jvanderbot 5y ago

jillesvangurp 5y ago

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 that, but "native" javascript just stopped being a mainstream thing quite a few years ago. That doesn't mean Javascript will go away but it does mean it now has to compete on merit rather than relying on it's status as the only thing that you can actually use in a browser. Many projects have already shifted to using Typescript for example. And from there to other transpiled languages is not that big of a leap. We use Kotlin-js for example. It's great. Other people use clojure, vue, elm or other languages that basically aren't javascript but that just happen to transpile to it. Long term WASM is a more efficient compiler target. Smaller, faster, easier to deal with for compiler builders, etc. The only remaining reasons to target browser js with your compiler, is that it still has better bindings to the browser APIs. This is something that is being worked on and of course that is more than offset by being able to compile existing libraries to WASM. WASM has a few other things as well that are still being worked on (threading, memory management/garbage collections, etc.). But long term, anything that javascript can do in a browser would be something you could do from a WASM compiled program as well. Once that works well enough, a lot more languages will start targeting browser applications just because they can. And a lot of developers that don't necessarily care about downgrading to Javascript might have a go at doing some applications that run in a browser. I predict a little renaissance in frameworks and tooling for this. And of course with WebGL and Canvas, using the DOM and CSS is entirely optional. For example Figma has a nice UI that looks like it would be hard to match with anything DOM based. They have a bit of react on the side for the bits that don't really matter but most of the app is C++. People also run games, virtual machines, etc. in browsers. There might still be valid reasons to use DOM + CSS like we have been for the last two decades. But it won't be the only choice for doing UIs. And being limited by it like we have been is increasingly no longer necessary either.

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

jayd16 5y ago

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.

jeremyjh 5y ago

Did you read the article or just the headline?

cies 5y ago
just the headline

tormeh 5y ago

> "I prefer to use strong typing and proofs to ensure it does not break at runtime" This has not been my experience with C++ (segfaults etc.) or Java (runtime introspection and exceptions). In ye olde languages compilation seems to be mostly (more than 50%) motivated by performance rather than correctness. Compiled languages have been doing steadily more compile-time work and improving ergonomics lately.

serverholic 5y ago

That rift has existed for a long time. There are some programmers who don't really care what tools they use as long as they feel productive. They shy away from things like types because it feels like it slows them down. Then there are programmers who care a lot about tools because it feels like the wrong tools hold them back and cause undue stress in the long-term. Hot take: The first type are less mature programmers :)

deleted 5y ago
[deleted]
erik_seaberg 5y ago
I do think some people feel productive writing more code, while others feel productive by finding ways to write less code (with the compiler mostly inferring and generating the error-prone and uncreative work).
deckard1 5y ago
> There are some programmers who don't really care what tools they use as long as they feel productive. They shy away from things like types because it feels like it slows them down. Right. The group that came up with the concept of a REPL and live in Emacs doesn't care about tools.

AprilArcus 5y ago

> 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 languages ever had* (and a few bad ones**), it is by now equally or more expressive by every metric. It's also the most popular PL in history, with a variety of maintained and opinionated libraries for every conceivable task. Given that JavaScript is already the ultimate flavor Objective-Blub, it makes no sense to write a JS-targeting transpiler for your favorite minor flavor of Blub. And since you're already targeting a browser, Lua's embedability and Python's C FFI are no advantages. The only remaining language in this family with interesting features that JavaScript hasn't (and may never) co-opt is Racket, with its powerful hygienic macros. To a lesser extent, this is also becoming true for the statically typed languages, where TypeScript*** offers a better developer experience than, and has made significant inroads against the faster but similarly expressive SML/OCaml/F#/Bucklescript/Reason/ReScript family (to say nothing of Java!). On the other hand, the camp of "I prefer to use strong typing and proofs to ensure it does not break at runtime" still has concrete advantages to bring to the world of FE dev, namely: • Non-GC memory management strategies suitable for latency sensitive applications (C, C++, Rust) • Static member lookup & method dispatch (C++, Rust) • SIMD (Rust) • Higher-kinded types (Haskell, PureScript) * block scope, destructuring assignment, default parameters, safe navigation, modules, iterators, generators, async/await, template strings, regexp named matches and lookarounds, BigInts ** classes *** While TypeScript is technically a compile-to-JS language, it is such a thin layer on top of JS that there is essentially no impedance mismatch between TS in an IDE and interactive debugging, which makes it unique within that category.

cies 5y ago
> The second group is incentivized to do so, because they still have value to bring. exactly.
addaon 5y ago
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.

deleted 5y ago

[deleted]