The melting pot of JavaScript (2017) • Hacker News Board

Re: The melting pot of JavaScript (2017)

#81

Post by winter_blue » Mon, Jan 07, 2019, 11:22 PM UTC

2trill2spill wrote: post #76

spricket wrote: post #26

I really like the kind of sanity that TypeScript brings to JS, super well designed and usually a pleasure to work with. That said, I've worked in many languages and I can't see any reason you would willing write your backend in JS or TypeScript. Java, C#, Rails, and to some extent Python are much saner choices. The massive churn of the JS ecosystem bleeds through to the backend, hard. JS could use a little more of th…

While I agree with you, I just started a new project and we need a decent amount of backend work done, and I wanted to do that in Golang, Java, or Rust, but no one else on the team knows Golang, Java or Rust, just Javascript and Typescript so it made sense to go with a language the team was good with. So far I'm liking typescript on the backend, especially because we use it on the frontend. Also my coworkers can give…

Seriously, not knowing the language shouldn't be a factor in choosing a language.

Just choose the best programming language, and everyone can learn it; and they'll be happy and grateful in the long run that they chose to learn this new language, rather than use whatever they were familiar with.

Moreover, Java is such a simple and an easy language to pick up. If the cruft is too much to deal with, go with Kotlin. An experienced developer could learn either language (Java or Kotlin) easily over a single weekend.

Re: The melting pot of JavaScript (2017)

#82

Post by _hardwaregeek » Mon, Jan 07, 2019, 11:30 PM UTC

spricket wrote: post #26

I really like the kind of sanity that TypeScript brings to JS, super well designed and usually a pleasure to work with. That said, I've worked in many languages and I can't see any reason you would willing write your backend in JS or TypeScript. Java, C#, Rails, and to some extent Python are much saner choices. The massive churn of the JS ecosystem bleeds through to the backend, hard. JS could use a little more of th…

I will say that isomorphic [1] JS apps are really fun to write because with well abstracted APIs, the back end and front end don't feel like a discrete API and a discrete front end, but one entity that communicates via asynchronous function calls. For instance, working with firebase functions just feels like working with a local async function. But that's really a minor benefit to the fair criticisms you give.

[1] Whoever came up with isomorphic really liked their fancy math terms. Personally I'd have chosen automorphic, as it's all contained inside JS.

Re: The melting pot of JavaScript (2017)

#83

Post by soneca » Mon, Jan 07, 2019, 11:31 PM UTC

_hardwaregeek wrote: post #78

soneca wrote: post #70

Earlier quoted context omitted.

Ember is exactly that. I love it and use it on my day job and on my side-project. But overall it doesn't have much adoption and no perspective to grow anymore.

I've wanted to use Ember, but I've never bothered to sit down and learn it. What ever happened to Glimmer? I remember it being hyped up as a crazy fast virtual DOM, but I haven't heard anything recently.

It was incorporated as the UI engine for Ember for some versions already for now.

Nothing revolutionary, but a good UI lib

Re: The melting pot of JavaScript (2017)

#84

Post by c-smile » Mon, Jan 07, 2019, 11:34 PM UTC

pitaj wrote: post #66

c-smile wrote: post #63

JavaScript was designed to be a glue language - to connect output of one native function with input of other native function. And do all of this in UI event handlers. And it was almost perfect (modulo hoisting, semicolon omission) for that. The trouble has started when Web, as a platform, has failed to provide safe alternative to JS aimed for extendable way of delivering and running high-performant code on the client…

> something close to JavaVM and HTML DOM exposed to it > ugly WebAsm WASM isn't fully functional as a standalone alternative to JS in the browser, yet, but you can essentially use it that way with things like wasm-bindgen in the Rust ecosystem. And it performs essentially what you're describing, being a VM running bytecode in a sandbox.

> but you can essentially use it that way

"Essentially" is a nice word. You can use it for example as JavaScript is a programming language, essentially, yeah.

W3C DOM was defined initially in terms of Java interfaces.

Where we would be now if we were allowed to run Java bytecodes in browser directly from the very beginning?

Today we might discuss -strip-dead-code option in your favorite compiler of XYZ language. Instead of fighting with would-be-linker npm.

Re: The melting pot of JavaScript (2017)

#85

Post by RussianCow » Mon, Jan 07, 2019, 11:35 PM UTC

winter_blue wrote: post #81

2trill2spill wrote: post #76

Earlier quoted context omitted.

While I agree with you, I just started a new project and we need a decent amount of backend work done, and I wanted to do that in Golang, Java, or Rust, but no one else on the team knows Golang, Java or Rust, just Javascript and Typescript so it made sense to go with a language the team was good with. So far I'm liking typescript on the backend, especially because we use it on the frontend. Also my coworkers can give…

Seriously, not knowing the language shouldn't be a factor in choosing a language. Just choose the best programming language, and everyone can learn it; and they'll be happy and grateful in the long run that they chose to learn this new language, rather than use whatever they were familiar with. Moreover, Java is such a simple and an easy language to pick up. If the cruft is too much to deal with, go with Kotlin. An e…

This isn't always a useful way to look at it. For a startup or small team especially, any time spent learning a new programming language is time spent not working on the core product. Yes, you might be better off in the long run using a more foreign programming language, but then again the business might not survive that long if you aren't actually building anything.

Also, it's easy to learn a language's syntax over a weekend, but it generally takes a lot longer to start being productive and writing idiomatic code in a new language, especially if you're also learning a new platform. That's time that you or your team may not have.

Re: The melting pot of JavaScript (2017)

#86

Post by orf » Mon, Jan 07, 2019, 11:37 PM UTC

pitaj wrote: post #68

orf wrote: post #47

Earlier quoted context omitted.

> Can you explain what Java offers with regard to reflection that JS doesn't? Among hundreds of other things, getting the return type of a method and getting the input parameter names (+ types) in a way that doesn't revolve around literally parsing the functions toString() representation. Oh, and typeof checking that isn't disgustingly broken.

> getting the return type of a method and getting the input parameter names (+ types) Type information literally doesn't exist at runtime, though. Isn't it kind of ridiculous to compare languages like that?

When you're comparing the relative power of reflection within the language, absolutely not.

Re: The melting pot of JavaScript (2017)

#87

Post by danenania » Mon, Jan 07, 2019, 11:39 PM UTC

bryanrasmussen wrote: post #42

spricket wrote: post #26

I really like the kind of sanity that TypeScript brings to JS, super well designed and usually a pleasure to work with. That said, I've worked in many languages and I can't see any reason you would willing write your backend in JS or TypeScript. Java, C#, Rails, and to some extent Python are much saner choices. The massive churn of the JS ecosystem bleeds through to the backend, hard. JS could use a little more of th…

JS or anything that compiles well to JS has a backend advantage that can be hard to beat for an early stage startup and that is reducing the amount of context switching you have to do in changing between languages (especially if your code is isomorphic). At least, that is how I find it, my productivity shoots up when I don't have to be moving between two imperative languages that most likely share a lot of their synt…

This advantage is further multiplied with TypeScript, since you can easily share types between backend and frontend. Working with a single set of types that enforce contracts (and supply IDE autocompletion) across the entire stack is amazing. It provides a huge productivity boost and eliminates a whole class of extremely common bugs.

Re: The melting pot of JavaScript (2017)

#88

Post by johnwyles » Mon, Jan 07, 2019, 11:40 PM UTC

2trill2spill wrote: post #76

spricket wrote: post #26

I really like the kind of sanity that TypeScript brings to JS, super well designed and usually a pleasure to work with. That said, I've worked in many languages and I can't see any reason you would willing write your backend in JS or TypeScript. Java, C#, Rails, and to some extent Python are much saner choices. The massive churn of the JS ecosystem bleeds through to the backend, hard. JS could use a little more of th…

While I agree with you, I just started a new project and we need a decent amount of backend work done, and I wanted to do that in Golang, Java, or Rust, but no one else on the team knows Golang, Java or Rust, just Javascript and Typescript so it made sense to go with a language the team was good with. So far I'm liking typescript on the backend, especially because we use it on the frontend. Also my coworkers can give…

My $0.02 but that is NOT a reason to use JS on the backend. That is an argument to cross-train or hire someone. It's like saying "We only had an expert on building houses made with straw so we chose straw." Because they know the language doesn't mean for one moment that that will make a good background there are so many concepts, services, paradigms and best practices that the language is probably the least of importance other than it should be something solid, robust, and battle tested which I would argue against with most JS backends although some are fairly well understood.

Re: The melting pot of JavaScript (2017)

#89

Post by johnwyles » Mon, Jan 07, 2019, 11:43 PM UTC

RussianCow wrote: post #85

winter_blue wrote: post #81

Earlier quoted context omitted.

Seriously, not knowing the language shouldn't be a factor in choosing a language. Just choose the best programming language, and everyone can learn it; and they'll be happy and grateful in the long run that they chose to learn this new language, rather than use whatever they were familiar with. Moreover, Java is such a simple and an easy language to pick up. If the cruft is too much to deal with, go with Kotlin. An e…

This isn't always a useful way to look at it. For a startup or small team especially, any time spent learning a new programming language is time spent not working on the core product. Yes, you might be better off in the long run using a more foreign programming language, but then again the business might not survive that long if you aren't actually building anything. Also, it's easy to learn a language's syntax over…

As I said above: hire someone new or invest the time to learn the language. Just because someone knows how to make a cute scarf using duct tape, safety scissors, and Elmers glue doesn't mean they should be building your backend driving the company 95 mph with seatbelts, airbags, and a chassis with crumple-zones.

Re: The melting pot of JavaScript (2017)

#90

Post by 2trill2spill » Mon, Jan 07, 2019, 11:48 PM UTC

johnwyles wrote: post #88

2trill2spill wrote: post #76

Earlier quoted context omitted.

While I agree with you, I just started a new project and we need a decent amount of backend work done, and I wanted to do that in Golang, Java, or Rust, but no one else on the team knows Golang, Java or Rust, just Javascript and Typescript so it made sense to go with a language the team was good with. So far I'm liking typescript on the backend, especially because we use it on the frontend. Also my coworkers can give…

My $0.02 but that is NOT a reason to use JS on the backend. That is an argument to cross-train or hire someone. It's like saying "We only had an expert on building houses made with straw so we chose straw." Because they know the language doesn't mean for one moment that that will make a good background there are so many concepts, services, paradigms and best practices that the language is probably the least of import…

Yea sure, but removing the language as a thing to learn makes it easier to learn concepts needed for programing on the backend. Besides were using Typescript, have automated tests, code reviews and Manual QA, I'm not worried about the code not being solid or robust.