Live data from Hacker News

The melting pot of JavaScript (2017)

increment.com

91–100 of 200 posts

Re: The melting pot of JavaScript (2017)

#91

Earlier quoted context omitted.

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.

Hiring someone is very time consuming, and requires paying another salary, benefits, etc. Also learning a new language takes time, yes a person can learn the basics of a language in a day or two, but it will be a long time before they are equally proficient with that new language.

Re: The melting pot of JavaScript (2017)

#92
post #74
post #61

Earlier quoted context omitted.

No. And that is also why JS is successful. Newbies with little oversight create new tools. Of thousands of them, one or two become popular because of non-functional reasons (right blog post, right fit, easy use, ..). Welcome to the mess :)

Tech pop-culture... Navigating these technology growth explosions is like searching for solid reference architecture in a booming shantytown. Some parts of these settlements eventually get things like running water, working sewage, urban planning.

Do not disagree to that. My comment is not a compliment to JS just a brutal analysis.

Re: The melting pot of JavaScript (2017)

#93
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

>also they frequently have good documentation and “getting started” tutorials. I tried making a TypeScript react app around Christmas, I found a tutorial, the commands did not work, I do not remember the details but it was using some bundler and probably the tutorial was a bit old and packages updated in npm. I found a different tutorial, to use create_react_app, I seen it uses npx(not sure when this tool appeared) i…

> I found a tutorial, the commands did not work

That’s hardly unique to Javascript. Back before the internet even existed I’d seen out of date make files which did nothing but spit out linker errors due to API changes in libraries.

Re: The melting pot of JavaScript (2017)

#94

Earlier quoted context omitted.

Java uses reflection and annotations to support all kinds of language extensions. Js has a lot of nasty issues with the "prototype chain" and annotation support is still experimental. For example, in java, scanning your classes and their annotations to generate code for them at compile time is a standardized feature. Maybe I'm just complaining that JS is too dynamic, but being able to generate code at compile time wi…

Do you have any concrete example for "For example, in java, scanning your classes and their annotations to generate code for them at compile time is a standardized feature"? Tip: in JS, I don't want OOP class. If you really want class, could you show me the intention behind it?

In general this what java annotation processors are all about. As a specific example, Dagger, a compile time, type safe dependency injection framework. https://google.github.io/dagger/

Re: The melting pot of JavaScript (2017)

#95

Earlier quoted context omitted.

Java uses reflection and annotations to support all kinds of language extensions. Js has a lot of nasty issues with the "prototype chain" and annotation support is still experimental. For example, in java, scanning your classes and their annotations to generate code for them at compile time is a standardized feature. Maybe I'm just complaining that JS is too dynamic, but being able to generate code at compile time wi…

Do you have any concrete example for "For example, in java, scanning your classes and their annotations to generate code for them at compile time is a standardized feature"? Tip: in JS, I don't want OOP class. If you really want class, could you show me the intention behind it?

Retrofit is another example: https://square.github.io/retrofit/

Re: The melting pot of JavaScript (2017)

#96
Let's say you'd like to write front-end code in a language that hides as much of the problems with JS as possible, preferably one that comes with a standard library, has elegant (or at least ergonomic) JS to interop and bridging, simplifies async code, and has a simple, integrated toolchain for targeting JS (all these amongst other things), what would you suggest? Basically what's the best language to write Javascript in : )

Dart? Elm? Clojurescript? Objective-J?

Re: The melting pot of JavaScript (2017)

#97

Earlier quoted context omitted.

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.

> Besides were using Typescript, have automated tests, code reviews and Manual QA, I'm not worried about the code not being solid or robust.

Oh god...

Yeah, no. None of this stuff is a substitute for actual code quality. Give me a good engineer that refuses to write tests over a mediocre one that does TDD any day.

Re: The melting pot of JavaScript (2017)

#98
post #97

Earlier quoted context omitted.

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.

> Besides were using Typescript, have automated tests, code reviews and Manual QA, I'm not worried about the code not being solid or robust. Oh god... Yeah, no. None of this stuff is a substitute for actual code quality. Give me a good engineer that refuses to write tests over a mediocre one that does TDD any day.

What kind of "good engineer" refuses to write tests?

Re: The melting pot of JavaScript (2017)

#99
post #93

Earlier quoted context omitted.

>also they frequently have good documentation and “getting started” tutorials. I tried making a TypeScript react app around Christmas, I found a tutorial, the commands did not work, I do not remember the details but it was using some bundler and probably the tutorial was a bit old and packages updated in npm. I found a different tutorial, to use create_react_app, I seen it uses npx(not sure when this tool appeared) i…

> I found a tutorial, the commands did not work That’s hardly unique to Javascript. Back before the internet even existed I’d seen out of date make files which did nothing but spit out linker errors due to API changes in libraries.

But it is way more common in JS. It got to the point that I do not trust tutorials that are not “official”.

Re: The melting pot of JavaScript (2017)

#100

Earlier quoted context omitted.

In JS there is a lot of convention but on a micro level. The times of monolithic Rails apps which have strict conventions are over and it's good: Too much magic and strict conventions often forced devs into patterns which didn't match the use case. Even experienced Rails devs tried to solve every problem the same way. You also confusing matters. You need Webpack, Babel etc for the frontend not the backend. And even i…

First, Webpack and Babel are totally used for backend. If you look at a lot of Node libraries, they use ES6 modules in their [docs]( https://github.com/graphql/graphql-js ). While you could use mjs for this, it's still experimental. I do think create-react-app is a good innovation in the JS world. However, I've never found a good equivalent on the back end. Setting up even the most basic CRUD REST API requires a whol…

> I do think create-react-app is a good innovation in the JS world. However, I've never found a good equivalent on the back end. Setting up even the most basic CRUD REST API requires a whole lot of typing for very little reward.

This is where services like Google Firebase Functions become useful.

I went from having never written a REST API in my life, to up and running in under 20 minutes.

First time I went to create some endpoints on my own server, wow, that was a pain.

Post reply on HN