Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The melting pot of JavaScript (2017)

increment.com

Post reply on HN
Print view View original

51–60 of 200 posts

Re: The melting pot of JavaScript (2017)

#51

Post by spricket »

undersheet wrote: post #33
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…

> Java, C#, Rails, and to some extent Python are much saner choices. Python not as scalable, Rails is stagnating, the ecosystem doesn't evolve anymore/dying, doesn't play well with SPAs, C# weak to none ecosystem outside of Windows and devs earn a fraction, Java verbose and dev productivity subpar (there was a reason people came up with Scala), Java devs also suffer lower salaries

I agree about critiques for most of those languages but not java.

If you reach out to the Java ecosystem you can find libraries, frameworks, and language extensions that make it relatively easy to code in. For example, with Lombok you don't have to write any getters and setters, or catch checked exceptions. Java 11 also makes good improvements to lamdas making method chaining a lot nicer. The Java I write at work is barely more verbose than the TypeScript, maybe 15% more code to do the same thing.

Java devs also get paid really well honestly, pretty sure it's better than the pay for JS and Python actually.

Re: The melting pot of JavaScript (2017)

#52

Post by spricket »

pwaivers wrote: post #27
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…

Since JavaScript is a prototype language, doesn't reflection come in automatically?

Bad/non-existent annotation support prevents you attaching metadata to objects without adding garbage to their structures. Makes reflection a lot less useful

Re: The melting pot of JavaScript (2017)

#53

Post by spricket »

orf wrote: post #47
orangeeater wrote: post #35

Earlier quoted context omitted.

> Js barely even supports reflection. This is a huge underrated shortcoming of js if you're doing anything complicated Can you explain what Java offers with regard to reflection that JS doesn't? My feeling is that reflection is almost moot in JS since you can inspect/mutate objects at runtime however you like. But maybe I'm missing the point of reflection. There is a Reflect object with a bunch of static methods on i…

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

Typeof is a good one, but holy crap I had no idea return type and param support was that horrific

Re: The melting pot of JavaScript (2017)

#54

Post by _hardwaregeek »

lewisjoe wrote: post #15
_hardwaregeek wrote: post #14

Very nice points here. I've always been struck at how the JavaScript community never really adopted the Rails ideas of convention over configuration and optimizing for developer happiness. While it's easy to roll one's eyes at the marketing lingo, these principles do truly make Rails a charm to use. Right now, even setting up the most simple Webpack-Babel-Node config requires writing a whole lot of config and set up…

Rails (or Python or Java) doesn't really fit into the problem set that JS has to go through. Most softwares written in those tech stay in the server with no need of transpiling, no need of code splitting when built, no need to be sent over the wire, etc. While I agree the package management in JS could have been better, most other too-much-config problem is just because of the variety of problems and the variety of p…

I'm not so sure about that. While there are a lot of complicated situations for JS dev, there's also a lot of similar patterns. I'm not saying we need to ignore the various complexities involved in JS dev, but we should make the general patterns easier to solve. Yes, of course transpilation can have all these different edge cases. But we should be able to have some preset modes that can do 90% of the work automatically. Like it baffles the mind that I still need to tell webpack that JSX files should be loaded by babel.

And anyways, there's the entire backend JS ecosystem, which is extremely behind Rails in developer ergonomics. I can spin up a REST API in Rails in half the time it takes to connect Node to a database.

Re: The melting pot of JavaScript (2017)

#55

Post by TeMPOraL »

spricket wrote: post #44
bryanrasmussen wrote: post #42

Earlier quoted context omitted.

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…

I find it's not an issue as long as you're using a decent "object shipping" layer like gRPC. Really greases up the transition point between different languages. I guess you could hire less proficient engineers which is a sell for startups, but I don't think it's worth the downsides of the current js ecosystem

It's not about RPC, it's about a way of DRYing code between the backend and frontend, using libraries as your copy-paste engine. You pull in the same library (or extract common code to a library) both on the page and on the server, and assume they're both identical.

I have mixed feelings about this. I don't feel comfortable with assuming that just because I use the same library in backend and frontend, I don't have to ensure consistency and behaviour. But then again, I've used this approach in one ClojureScript project (ClojureScript can transpile a lot of Clojure libraries to JS), and it is convenient.

Re: The melting pot of JavaScript (2017)

#56

Post by orf »

orangeeater wrote: post #49
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.

> 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. Ah, that's quite cool.

You can do almost anything with Java reflection, JS really pales in comparison.

Which in some ways is a good thing as you can do a lot more optimizations.

Re: The melting pot of JavaScript (2017)

#57

Post by bryanrasmussen »

spricket wrote: post #44
bryanrasmussen wrote: post #42

Earlier quoted context omitted.

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…

I find it's not an issue as long as you're using a decent "object shipping" layer like gRPC. Really greases up the transition point between different languages. I guess you could hire less proficient engineers which is a sell for startups, but I don't think it's worth the downsides of the current js ecosystem

sure that answers part of the isomorphic problem (but not all), but it still leaves me writing code in two languages that often have lots of similarities in how they look but funny little differences in how they behave that either slow me down or cause me to put in bugs because I'm tired because it's a small startup situation.

Re: The melting pot of JavaScript (2017)

#58

Post by TeMPOraL »

gedy wrote: post #25
perfunctory wrote: post #8

Earlier quoted context omitted.

Really curious what is actually wrong with "crude bash scripts for building"? I had experience with both types of projects - the ones with home made crude build tools (in Python, not bash), and the ones with modern javascript build pipelines. The first build never broke. The second build would break every couple of months for no obvious reason without us touching the project structure.

Maintenance. Because seems they are usually written/owned/optimized by some build brainiac that becomes a bottleneck or leaves at some point.

The equivalent "modern" workflow is written, owned and optimized by build brainiacs with turnover on the order of weeks. I'd say that maintenance of "crude shell scripts" is much less difficult and expensive than keeping up with the latest webdev "standard practice".

Re: The melting pot of JavaScript (2017)

#59

Post by oaiey »

kibwen wrote: post #45
hrabago wrote: post #23

Earlier quoted context omitted.

Ten years ago, JavaScript was my go to when I wanted to expose others to coding. It still is today, but now that comes with the caveat that the most popular libraries and framework require a significant amount of prior knowledge to understand and to start using. I haven't done this exercise in a long while, but the last time I tried to start a project from the "most current and stable releases and recommendations", I…

JavaScript is still what I use to introduce programming to new people, because for people who haven't done their dues learning how to use a command-line, the hardest part of getting started with programming is getting your computer set up to do it at all. And since everyone already has a browser, getting started with coding only requires showing them how to open the developer console.

Fair, but most stacks including the previous infamous ones are two or three lightweight installs away. The VSCode/Atom/Sublime generation of IDE replacements made that possible.

I come from an environment (.NET) where setup was a day or two of work but now is a matter of 10 or less minutes).

Re: The melting pot of JavaScript (2017)

#60

Post by [deleted] »

hrabago wrote: post #23
zach43 wrote: post #11

I personally think that the JavaScript community is doing a great job with its tooling and approach. Compared to other language environments I’ve worked with (C, C++, Python), most common JS tools work in predictable, user-friendly ways...also they frequently have good documentation and “getting started” tutorials. It is good to see that the community is open to introspecting and improving even further

Ten years ago, JavaScript was my go to when I wanted to expose others to coding. It still is today, but now that comes with the caveat that the most popular libraries and framework require a significant amount of prior knowledge to understand and to start using. I haven't done this exercise in a long while, but the last time I tried to start a project from the "most current and stable releases and recommendations", I…

[deleted]
Post reply on HN