Live data from Hacker News

Ask HN: Why is everything in JavaScript changing so fast?

news.ycombinator.com

261–270 of 303 posts

Re: Ask HN: Why is everything in JavaScript changing so fast?

#261
post #148

Earlier quoted context omitted.

Who needs more than one language? One language is all we need? Who needs Assembler or C or LISP or HTML or CSS or Bash Script or Python or Perl??? WHO NEEDS THAT? SINGLE STACK!! /s

They (kind of) have a point though. I agree you should aim to be polyglot, but a particular project may not afford the learning curve if the dev doesn't already know the best stack. For example, I'm working (part time) on a relatively simple backend server for a nonprofit with a tiny budget and short deadlines. I know I can do it cheap and fast in Python, and it will work "ok". Go would be better, and I'd like to lea…

Well, it's certainly not something that needs to be avoided at all costs but in the long term it can be less efficient and more costly.

It depends really, there is no single true language (except LISP) to solve all problems in the entire stack.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#262

In an industry without a guild / license / what have you, the incentives skew towards articles of proof. Articles of proof could be demo websites, screen shots, and open source libraries. Being the creator or top two contributor of a library is now worth so much more than being a small time contributor that the incentives are skewed towards everyone just making a new thing, always. It's their way to stand out. So why…

> default async is a terrible setting Haskell's version of "everything is async" works wonderfully. It's JavaScript that is bad, not the concept.

False. There is async/await, or generators. Its ES5 that is bad, not JavaScript.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#263
post #261

Earlier quoted context omitted.

They (kind of) have a point though. I agree you should aim to be polyglot, but a particular project may not afford the learning curve if the dev doesn't already know the best stack. For example, I'm working (part time) on a relatively simple backend server for a nonprofit with a tiny budget and short deadlines. I know I can do it cheap and fast in Python, and it will work "ok". Go would be better, and I'd like to lea…

Well, it's certainly not something that needs to be avoided at all costs but in the long term it can be less efficient and more costly. It depends really, there is no single true language (except LISP) to solve all problems in the entire stack.

All hail LISP.

My main problem with LISP is that I stopped liking Python after learning it.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#264
post #53

Earlier quoted context omitted.

I think out of all the comments so far this passes closest to the real reason. It's simple: if you're developing for the web, you almost certainly have to use Javascript . That reality corrals so many more people into Javascript than any other language.

That is certainly part of the reason, but other platforms enforce language choices and don't have the same level of churn. Two popular mobile platforms come to mind.

You don't have to use Java on Android and you don't have to use Objective C or Swift on iOS. You're heavily corralled towards them, but there are still other options.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#265

In an industry without a guild / license / what have you, the incentives skew towards articles of proof. Articles of proof could be demo websites, screen shots, and open source libraries. Being the creator or top two contributor of a library is now worth so much more than being a small time contributor that the incentives are skewed towards everyone just making a new thing, always. It's their way to stand out. So why…

On the other hand, Go's type system is so bad that it nullifies all the benefits it brings to the table. I'd rather have no type system than Go's type system, but why even ponder that if I can have everything? With JS I can start out with dynamic types, then switch to static types if the need arises (typescript, flow), fully or partially. Oh, and both of those have really good generics btw.

And we have async/await too now, which means async code can also look almost the same as sync code. So I would still choose JS over both Python and Go (at least for that particular use case). mypy still has long ways to go before its anywhere near TS or Flow.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#266
post #261

Earlier quoted context omitted.

They (kind of) have a point though. I agree you should aim to be polyglot, but a particular project may not afford the learning curve if the dev doesn't already know the best stack. For example, I'm working (part time) on a relatively simple backend server for a nonprofit with a tiny budget and short deadlines. I know I can do it cheap and fast in Python, and it will work "ok". Go would be better, and I'd like to lea…

Well, it's certainly not something that needs to be avoided at all costs but in the long term it can be less efficient and more costly. It depends really, there is no single true language (except LISP) to solve all problems in the entire stack.

[deleted]

Re: Ask HN: Why is everything in JavaScript changing so fast?

#267
post #250
post #215

Earlier quoted context omitted.

As an outsider to the community, I see it as a pathology that there are people you are supposed to recognize outside of the language creator. Not that a culture is a bad thing but in a healthy technical community recognition should come from decades of hard work - not from a nice landing page and a framework of the week. IMO, social media and blogosphere driven complex work cannot be deep, just confused.

I think its democratic which is the best system we have. Any kid with a new idea can have his ideas listened to. This means we don't get stuck.

Democracy is not about deep work, thorough understanding or the best architecture. It's about negotiating compromise in a situation where there is no shared goal. It works great for ruling countries where it's sluggishness and confusion is a feature and not a bug.

I would claim that any technical undertaking without understood goals using a process whose main design feature is not efficiency but sluggishness is a pathological one.

A computer system is far more simpler than any countrys political system - it's tractable and optimal solutions can be found. Unless, of course, unless the design process is lost in confusion and bafflement.

I would claim a place where any kid is listened to is precisely the one where everyone will get stuck. If people spend more time reading blogs rather than on CS basics they cannot understand a great ideas because they are on the Kruger-Dunning level of skill development.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#269

Earlier quoted context omitted.

> how most people actually want to write software. [citation needed] Honestly, Rails wasn't the first or last RAD platform and I don't think a randomly-selected subset of programmers who have used it would describe it as a shining beacon of light. JS frameworks are actually pretty diverse, and if you think the ecosystem is a bunch of MV* variants just waiting for something innovative to come along, with respect, you…

> [citation needed] Okay. The year is 2005. PHP5 was fresh out of the oven and most people were still on PHP4. From PHP's point of view, there's rumors of something happening in the Ruby community that will be big, and should be talked about [1]. Then Rails 1.0 drops at the end of the year. From this Slashdot thread [2] on the announcement you can gauge the contemporary reaction; comments detail the fact that Rails w…

> Groovy on Grails

The source you quote says "Groovy on Rails", which was the official name until it was contracted to "Grails" due to the insistence of the Rails crowd that "on Rails" not be used in any other product names. The "Groovy on Grails" phrase you wrote was a later unofficial but intended mispronunciation of the earlier name put out by the Grails crowd to make it sound like "Ruby on Rails" as a snipe at the Rails crowd. To those of us who thought Groovy would make a good language outside of its use in Grails, the mispronunciation made it sound like someone in the Grails crowd thought Groovy's only use was for scripting Grails.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#270
post #16

The open-source-JavaScript community right now is just the largest, most active open source community that has ever existed. Check out the stats that GitHub recently announced: https://octoverse.github.com/ Open source JavaScript activity as measured by pull requests has doubled (!!) in the past year. It's more than the next two languages (Java and Python) combined. Most of the top repositories on GitHub are JavaScri…

You have to be careful with the GitHub stats. I have a few Python/Ruby projects that GitHub categorizes as JavaScript because I have a few 3rd party JavaScript dependencies that ended up being larger than my actual project.

These libraries were checked into Git because it was more convenient at the time and I hadn't set up a good build system, as they were non-critical side projects.

I know I'm not the only one who has done this in the past. I'd be curious to see GitHub stats that tried to account for this.

Post reply on HN