Live data from Hacker News

The other kind of JavaScript fatigue

chrismm.com

61–70 of 99 posts

Re: The other kind of JavaScript fatigue

#61
post #41

Remember Google’s Polymer? Angular 1? Express? Perhaps the organizations and individuals which cause these abrupt termination events should carry a stigma. A fantastic idea. There should be some social consequences for these sort of faithless and feckless types.

Angular 1 is a shame, and it's absolutely right that it shouldn't have been abruptly replaced (though not terminated). But polymer was and still is barely an alpha, and was practically not used for any real usage (which isn't basically a showcase). Express is 7 years old and still running strong, continuously being updated and was not terminated or abandoned. Kue.js is just an extension of Express.js with new ideas t…

Yeah, I still use Express all the time. I wouldn't put it--or Angular 1--on that list.

Re: The other kind of JavaScript fatigue

#62
post #32

Earlier quoted context omitted.

I think it's rather that the java and .net framework are pretty good out of the box. So there is only a need for additional framework for certain corner cases. And then some get bought by Microsoft and integrated out of the box, like the datavisualization libraries or xamarin. JavaScript on the other side is a language that only its conceptor could love. All these frameworks are sort of required to be barely producti…

Ehh... When there are many questions on SO asking how to read a file in Java and the answers all require about a dozen LOC and have hundreds of upvotes [0,1,2] I think I agree with the earlier comment that it's more a barrier to distribution and acquisition of modules. There are plenty of tiny npm modules that do less than a Java wrapper for easily reading files would. [0] http://stackoverflow.com/questions/4716503/r…

I am not familiar enough with java which I assumed was a match for .net. But one line of code in .net.

IO.File.ReadAllText(FilePath)

Re: The other kind of JavaScript fatigue

#63
post #28

Earlier quoted context omitted.

Github seems to want to be a social media site first and a git host second. Which is why I exclusively use Bitbucket now.

Why is socializing with other programmers a bad thing? They manage the core repo hosting quite well. They also act like a solid CDN.

>Why is socializing with other programmers a bad thing?

It's not - socializing with programmers is why I'm on Hacker News. But, socializing isn't what Github should be about. Github should be about development, first and foremost. Having issues and comments support pointless features like emoji and voting and images (and image memes) dilutes the focus of the site and moves it towards being just another forum.

Also, having Github act as a social network injects trolling, politics and drama into the development environment, and I believe development should be apolitical and acultural. I dread the (extremely unlikely) prospect of publishing a project to Github that actually becomes popular and accepting a PR from someone whose political views I may personally despise, but whose code is acceptable, or the backlash if I don't abide by a particular Code of Conduct. Not everyone wants to deal with the cesspool that is modern "social coding" or to build a "community" or to have the number of stars on their account validate their resume.

I just want a place to host code and maybe take pull requests and not have to pay for the privilege of having a private repo.

Re: The other kind of JavaScript fatigue

#64
post #3

Realized this sometime ago, when I was wondering why the Java ecosystem doesn't have this problem. It boils down to the barrier of entry. On JS it's so low as to be almost nonexistent, which is why you end up with junk like isPositiveInteger. Slap some shit together and ship it. You can't do that easily in Java. You need to spend some time understanding the language, the ecosystem, how to bundle your code into an art…

That's why there's JSweet, the Java to Javascript transpiler. http://www.jsweet.org/

Transpilers have their own issues.

Source: I spent years developing with GWT

Re: The other kind of JavaScript fatigue

#65

Earlier quoted context omitted.

And you are wasting huge amounts of time by rewriting stuff that's already out there tested by thousands of people. Also collaborating with others becomes much more challenging because you invendted everything. With experience I can minimize self written code and I can skip plugins and libraries, but I feel better if I can rely on something solid. It does not apply to all field of programming per se, but web develope…

"Trying to build a framework to understand frameworks" is not the same as "use you own frameworks on your professional projects" I have written my own Forth, my own filesystem, my own Mvc etc. etc. and I would say they have improved my skill more than learning a new Algol derived language but I would never advocate their use in production.

For learning it's a good idea to make something from scratch, way better than writing todo apps :) It can even be better than the original one. For productivity it's not the case however.

Re: The other kind of JavaScript fatigue

#66
post #62

Earlier quoted context omitted.

Ehh... When there are many questions on SO asking how to read a file in Java and the answers all require about a dozen LOC and have hundreds of upvotes [0,1,2] I think I agree with the earlier comment that it's more a barrier to distribution and acquisition of modules. There are plenty of tiny npm modules that do less than a Java wrapper for easily reading files would. [0] http://stackoverflow.com/questions/4716503/r…

I am not familiar enough with java which I assumed was a match for .net. But one line of code in .net. IO.File.ReadAllText(FilePath)

Yeah, .net is way nicer than java and your argument holds pretty well in that case.

Re: The other kind of JavaScript fatigue

#67
post #24

Earlier quoted context omitted.

> What this article is about? Snippets from SO answers are not as good as battle-tested code? It's obvious and it's same in all languages. It's much harder to ship SO copypasta in say, Java or C#, than in Node. JavaScript is a much easier language to grasp and it is also a lot more forgiving and loose. Combine that with NPM and can suddenly be immensely "productive". But the ability to write and push a lot of code ve…

It only depends on programmer. Somebody copy-paste from SO to production, somebody write tests and run them before deployment. There is a lot of dynamic ("forgiving") languages, so JS is not unique here.

This is not about pushing code to production. I don't deny that problem exists in Java. This is about the quality of libraries and frameworks.

Re: The other kind of JavaScript fatigue

#68
post #24

Earlier quoted context omitted.

> What this article is about? Snippets from SO answers are not as good as battle-tested code? It's obvious and it's same in all languages. It's much harder to ship SO copypasta in say, Java or C#, than in Node. JavaScript is a much easier language to grasp and it is also a lot more forgiving and loose. Combine that with NPM and can suddenly be immensely "productive". But the ability to write and push a lot of code ve…

It only depends on programmer. Somebody copy-paste from SO to production, somebody write tests and run them before deployment. There is a lot of dynamic ("forgiving") languages, so JS is not unique here.

This is not about pushing code to production. I don't deny that problem exists in Java. This is about the quality of libraries and frameworks.

Re: The other kind of JavaScript fatigue

#69

Earlier quoted context omitted.

It only depends on programmer. Somebody copy-paste from SO to production, somebody write tests and run them before deployment. There is a lot of dynamic ("forgiving") languages, so JS is not unique here.

I've seen people change Java code in production to fix a bug and recompile it. This is hardly a behavior that exists only in dynamic languages.

That's a different issue entirely. The article is talking about the quality of frameworks and libraries in JS.

Re: The other kind of JavaScript fatigue

#70
post #32
post #3

Realized this sometime ago, when I was wondering why the Java ecosystem doesn't have this problem. It boils down to the barrier of entry. On JS it's so low as to be almost nonexistent, which is why you end up with junk like isPositiveInteger. Slap some shit together and ship it. You can't do that easily in Java. You need to spend some time understanding the language, the ecosystem, how to bundle your code into an art…

I think it's rather that the java and .net framework are pretty good out of the box. So there is only a need for additional framework for certain corner cases. And then some get bought by Microsoft and integrated out of the box, like the datavisualization libraries or xamarin. JavaScript on the other side is a language that only its conceptor could love. All these frameworks are sort of required to be barely producti…

That's a very good point. The standard library for JavaScript is embarrassing to say the least. But you can't really fault it given the environment for which it was created. Node went some way towards making it a little better at least for the server side.
Post reply on HN