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

The other kind of JavaScript fatigue

chrismm.com

Post reply on HN
Print view View original

31–40 of 99 posts

Re: The other kind of JavaScript fatigue

#31

Post by branchless »

vivin wrote: 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…

This is kind of funny because this is what other devs say about java.

I don't mean to bucket all java devs as bad, many are great and it's a credit to the language that it is easier to start using than c++.

Re: The other kind of JavaScript fatigue

#32

Post by cm2187 »

vivin wrote: 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 productive. Which is why you end up with these big frameworks to abstract the various browsers, introduce databinding, or add static typing.

Re: The other kind of JavaScript fatigue

#33

Post by stevesun21 »

vivin wrote: 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…

Agreed, another reason I guess is because people in Java community is deciplined developers (they have to be since day one) – aware of data structure, time complexity and some CS principles.

Plus the open source community includes some Apache kind sub communities in which developers are really persistent and proud to commit to what they are building.

Re: The other kind of JavaScript fatigue

#34

Post by felixgallo »

cyberpanther wrote: post #23
vivin wrote: post #17

Earlier quoted context omitted.

I guess my experience with CPAN has been different. Probably the most frustrating thing is the paucity of documentation from certain perl modules. But the modules I've found and used have been pretty good quality and pretty stable. Then again, I've never built anything "enterprisey" in Perl (just little tools and scripts here and there), so that could it be it.

I think you might have hit something here. Because Perl is definitely hard to read and with bare documentation, the module might have been fine but we just never knew how to use it.

Perl can be hard to read, but it has incredible documentation and CPAN set (and apparently still keeps) the diamond standard for language packages and distribution systems.

Re: The other kind of JavaScript fatigue

#35

Post by douche »

thesmart wrote: post #26
nzoschke wrote: post #19

I see his point and I think another dimension of the tooling is a root cause too... > Recently I needed a library to build query strings, just a small one so that I wouldn’t have to include jQuery just for that. After a couple of hours of research... jQuery clearly is the best library to look to for a mature implementation. So why not just use it? Hours looking for alternatives is actually really expensive. The justi…

jQuery, while mature and great, is fairly unnecessary considering all that HTML5 and ECMA maintainers have accomplished since jQuery matured.

Unless you are unlucky enough to still be locked into the (thankfully ever shrinking) world of enterprise web apps, where stuff needs to work on old, unupdated version of IE.

Re: The other kind of JavaScript fatigue

#36

Post by jaequery »

"Embrace change, and it will make you a better developer."

I don't agree with this at all. I think a good coder has complete mastery of their code and tools which is only possible by putting significant time to use one thing instead of jumping one thing to the next ever so often.

Imo the best way to become a better developer is not by using what others have created but trying to create libraries and frameworks yourselves to truly understand or at the very least think about the in and outs of the code to think throughly and produce a better architecture. It will open up your eye to differentiate good and bad code rather quickly.

Re: The other kind of JavaScript fatigue

#37

Post by Bahamut »

n0us wrote: post #25

One factor that leads to fragmentation is this "theme" that I seem to see over and over that when a project is popular the creator gets to be the github maintainer and take credit for it's success as a large and popular project, which by itself is a good thing. The bad part is that when the maintainers make unpopular decisions like disabling all functionality by default and relying on submodules, or not wanting to fi…

Most open source maintainers are developers who work full time - I am a maintainer of a major project, but there are times my activity is light, such as the past two months. In that time, I travelled to Salt Lake City, Reno, Portland, San Diego, Seattle, and now in route to Chicago - I ran a half and full marathon in that time, and about to run another half tomorrow morning. I am currently in crunch time at my current job for the past two weeks, and I am about to leave for a well earned 2 1/2 week vacation to England, France, Switzerland, and Italy. I don't plan on coding much, if at all, while in Europe.

I very much enjoy working on open source, and have implemented some tricky but highly useful features over the past almost 1 1/2 years of my stewardship that users greatly appreciate. However, I also have a rich life outside of development as well, and I believe that each persons' choices with how they choose to use their time should be respected. If you are not paying or contributing your own time feature developing or assisting maintainance, complaining about maintainer absence is really poor. We are not on demand tech support.

Re: The other kind of JavaScript fatigue

#38

Post by jakobegger »

nzoschke wrote: post #19

I see his point and I think another dimension of the tooling is a root cause too... > Recently I needed a library to build query strings, just a small one so that I wouldn’t have to include jQuery just for that. After a couple of hours of research... jQuery clearly is the best library to look to for a mature implementation. So why not just use it? Hours looking for alternatives is actually really expensive. The justi…

Jquery can take several seconds to download on a mobile connection. If you think several seconds of lag for every first time visitor is acceptable, you clearly have a different set of priorities than I do.

Re: The other kind of JavaScript fatigue

#39

Post by Illniyar »

There is another upside to modules being easy to make and publish - they are also easy to change.

The query parser you want isn't able to handle nested objects and arrays easily - fork it, add your small piece of code (to what is hopefully an already small module), use it with a direct reference in your package.json, send a pull request upstream.

The fact that libraries don't handle your specific edge case/ special need is not unique to javascript, atleast you have an easy way out in node's mentality of small modules. Try getting a small change to work in spring or hibernate or any of the other massive frameworks that require days only to get familiar with their api and lifecycle hooks.

Consider this, I can easily go into the most popular framework in node (express.js) and change any part of the code within a few hours to match what I want, including adding tests, and there is non-zero chance that my changes will be pushed upstream. If I ever needed to do this to Spring MVC or even Racket, it will take me weeks, would most likely end up breaking dozen of other edge cases and would never be accepted by the Foundations managing those projects.

Re: The other kind of JavaScript fatigue

#40

Post by nzoschke »

scotttrinh wrote: post #22
nzoschke wrote: post #19

I see his point and I think another dimension of the tooling is a root cause too... > Recently I needed a library to build query strings, just a small one so that I wouldn’t have to include jQuery just for that. After a couple of hours of research... jQuery clearly is the best library to look to for a mature implementation. So why not just use it? Hours looking for alternatives is actually really expensive. The justi…

> Next, the dynamic nature of JavaScript is to blame. You can't easily extract and compile just the functions you need. Definitely check out rollup, if you haven't heard of it. We (the JavaScript community) are working towards solving this!

Thanks for the tip, rollup looks really powerful.

This and related comments remind me that the latest ECMA stuff offers a brighter future. The challenge is getting there...

Can/will jQuery work with rollup and all the other new module work? Or does it have to be effectively rewritten?

Post reply on HN