Hacker Newsnew | past | comments | ask | show | jobs | submit | undersheet's commentslogin

I disagree. Assume you are an average coder, you should have a clue of basic JS:

1 week to learn JS latest language features

1 week to grok node, npm and the power of the JS object

1 week for React, basic stuff not redux

1 more week to dabble around

4 weeks and you should be able to be productive JS with its most important flavors. Tell me any other ecosystem where you are that fast.


JS is not your daddy's JS anymore.


> cognitive load of tool options

First time I hear options are bad. Many options and competition lead to best products. There are enough posts and people who tell you what you should use.

Or just use npmtrends or npmcharts. 1 second later you know what is going on and what module you should pick.

Why are people criticizing something they have never used?


My point here on this one is simply that it's investing to think about this factor. For beginners (which I am not), too many options can be confusing. That said, setting reasonable defaults for detail options so things work well without needing to configure then to start is a nice way around this. Deep options exist and can be adjusted as needed but a solid default configuration is set out of the box. "There are enough posts and people who tell you what you should use." -- sure but what if opinions very widely? There's the cognitive load or put another way friction-to-first-use.


who said that JS is for beginners?


Just to be clear - you don't think the author has ever used a tool with too many configuration options?


> 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


> Python not as scalable

Not scalable in what way? Every aspect of scalable that I can think of is in no way limited by choosing python as your language.


> I can think of

Mayne that is your problem. Try new stuff. V8 is still one of the fastest and most optimized VMs.


That has absolutely no relationship to backend scalability whatsoever.


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.


Python maybe but JS not. React devs are paud higher than any Java coder.


"Rails... ...doesn't play well with SPAs"

Huh? Rails ships with built-in, no-config webpack support (https://github.com/rails/webpacker#installation) as well as install tasks for the most-popular front-end solutions (https://github.com/rails/webpacker#integrations)


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 in the frontend it got abstracted away by things like creat-react-app. So you shouldn't them see them too often.


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 whole lot of typing for very little reward.

As for convention, I think JS could do with more of it. I find that when I talk about adding more convention, people take it quite literally as "we need to reinvent Rails in JS". That's not at all what I mean. Convention can be something as simple as Rack, which is a consistent, useful interface between servers. Convention does not and is not tied to monoliths or MVC or any other aspect of Rails.


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


Firebase is a dream. It's almost a shame they got bought by Google because it's such a fantastic idea. All of the things I used to dread setting up (auth, deployment, serverless) are automated and dead easy. The documentation is clear and caters to the common usecases. I managed to set up a Sendgrid email that sends on database writes within an hour or two.


> The documentation is clear and caters to the common usecases.

I wouldn't quite say that, but I'll agree with your other points. :)

(More than once the docs have been out of date, or just flat out wrong, costing me many hours of development time...)


JS is so good for APIS because of its dynamic JS objects. If you then take also a document storage you don't need any ORM anymore and write your entire API in 5 mins. Rails was a nightmare compared. JS lets you do stuff yourself. You don't any framework holding your hand. Maybe that's your problem.


In what world you think the usability of a language is determined by being able to get a Restful API up in 5 minutes?

Yeah, document storage for business-critical data. I'll pass. There's a reason important data gets stored in Postgres.


Simply not true. Rails continues to be the choice for many companies who don't base tech choices on what the latest bandwagon is.

JS is mess.


I love Github for open source and the community but for private repos I like But bucket more. Don't know why but the overall interface feels cleaner, less cluttered.


> I’ve been integrating a bootstrap framework

You do this for legacy systems. New systems should not use Bootstrap, there is much better out there.


Don't be so dogmatic - Bootstrap works just fine, and if it's what you know, you need some very good reasons to switch and learn a new framework.


Not about being dogmatic. Bootstrap is just wrong in 2019.


I agree but this type of comment also shows your lack of experience. Very rarely do you personally get to make a choice about the technology used. In this case I’ve come onto a project to fix a load of bugs and restyle something that already existed. I’m not going to come in and redo everything from scratch before delivering something...


OK, so how am I supposed to take a reply like this - it sounds... well, dogmatic!

Given you haven't even attempted to explain your reasoning, I can't possibly agree.


What should I use instead of Bootstrap in 2019 then?


What's the best in 2019?


This feels like an orchestrated upvoting and content marketing flash mob from the Elixir Slack channel. Google Trends shows that Elixir is declining. I love new languages but don't like to be fooled.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: