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

71–80 of 99 posts

Re: The other kind of JavaScript fatigue

#71

Post by krapp »

cm2187 wrote: post #60
douche wrote: post #56

Earlier quoted context omitted.

Javascript has a terrible embarrassment of a standard library. Things that should just be baked into the language are not, which has lead to attempts to rectify that shortcoming, like jQuery, Underscore and LoDash. Because this standard library isn't implemented in the browser itself, where it belongs, people have gotten upset about downloading a few hundred kbs of a general purpose utility library, and instead reimp…

And not just in javascript. HTML is largely the culprit too. A lot is done in javascript that HTML should really handle. For instance why can't we just add a URL attribute to an input to provide autocomplete and validation. It is such a common scenario there shouldn't be a need for a javascript framework to provide that. Same thing with responsive design. But these technologies are stuck in the 90s and barely evolve…

>For instance why can't we just add a URL attribute to an input to provide autocomplete and validation.

You can. is part of HTML5[0].

Of course, support may not be universal[1], which is why you will probably always have to use javascript if cross-compatibility matters.

[0]https://www.w3.org/TR/html-markup/input.url.html

[1]http://caniuse.com/#feat=input-email-tel-url

Re: The other kind of JavaScript fatigue

#72

Post by vivin »

Illniyar wrote: post #39

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 n…

Not my experience. I recently submitted a bug fix to Qt WebKit and feature to swagger. Neither of them broke anything and both were accepted. The submission processes for both projects were diligent enough to ensure quality contributions yet simple enough that they were not byzantine.

Re: The other kind of JavaScript fatigue

#73

Post by [deleted] »

Illniyar wrote: post #39

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 n…

[deleted]

Re: The other kind of JavaScript fatigue

#74

Post by cm2187 »

krapp wrote: post #71
cm2187 wrote: post #60

Earlier quoted context omitted.

And not just in javascript. HTML is largely the culprit too. A lot is done in javascript that HTML should really handle. For instance why can't we just add a URL attribute to an input to provide autocomplete and validation. It is such a common scenario there shouldn't be a need for a javascript framework to provide that. Same thing with responsive design. But these technologies are stuck in the 90s and barely evolve…

>For instance why can't we just add a URL attribute to an input to provide autocomplete and validation. You can. is part of HTML5[0]. Of course, support may not be universal[1], which is why you will probably always have to use javascript if cross-compatibility matters. [0] https://www.w3.org/TR/html-markup/input.url.html [1] http://caniuse.com/#feat=input-email-tel-url

No by URL I meant the URL of the service that would provide the autocomplete or the validation. Like:

Re: The other kind of JavaScript fatigue

#75

Post by jmiserez »

ourmandave wrote: post #9
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…

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

I used jDojo (by IBM Rational) and it was great. It's a similar transpiler Java->JavaScript, with support for the Dojo Toolkit. One cool thing is that it's very easy and fast to define your own stubs for whatever library you are using, e.g. I added stubs for most of CKEditor and it was painless. The resulting output looks pretty much 1:1 like the Java code, which makes it easy to debug. Unfortunately their website is not viewable without an account: https://jazz.net/wiki/bin/view/Main/JDojo Twitter: https://twitter.com/jdojo

Re: The other kind of JavaScript fatigue

#76

Post by jmiserez »

mooreds wrote: post #64
ourmandave wrote: post #9

Earlier quoted context omitted.

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

GWT is a very different beast, it's more of a framework with widgets and everything. When I tried it (a few years ago) the resulting JavaScript looked nothing like the Java code. If the Java code you write looks almost identical to the native JavaScript produced you don't really lose much, but you can refactor more easily etc.

Re: The other kind of JavaScript fatigue

#77

Post by elmigranto »

Illniyar wrote: post #48
g8oz wrote: 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…

I think you meant Koa.js, not Kue.

Re: The other kind of JavaScript fatigue

#78

Post by awalGarg »

cyberpanther wrote: post #14

This is nothing new, JS just evolved the problem to the next level. Perl and CPAN had notoriously bad modules and each subsequent language has made packaging easier. And now JS is available with easy packaging or just by including a URL to the package. This problem is inevitable. JS just is the current most widely distributed and used language. I think we have to learn live with crap code and find ways to surface the…

I think the current "rating system" is basically number of github stars. Not sure if I am actually happy with that, or even want a better version at all.

Re: The other kind of JavaScript fatigue

#79

Post by pdimitar »

mooreds wrote: post #64
ourmandave wrote: post #9

Earlier quoted context omitted.

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

Agreed. Transpilers are saving you nerves initially at the expense of making you want to commit suicide later. Like when you need to debug in real time, or check underlying "native" objects, or when a library the transpiler is relying on has a bug.

IMO transpilers are a Faustian deal. That's what my experience has taught me, your mileage may vary of course.

Re: The other kind of JavaScript fatigue

#80

Post by pdimitar »

jaequery wrote: post #36

"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 yourse…

With respect, I think you're missing the point. Embracing change in this instance means to bare witness to how much differently people approach a problem compared to you (or the common wisdom). This is an eye-opening process that enriches your neural paths immensely. It shows you alternatives and it's making you more inquisitive in your work.

IMO the premise of the article is that while this process is productive and educational, it's not something that you want to do all the time. Sooner or later you learn enough to be a world-class professional. At this point, checking what every kiddie with a keyboard and a monitor can code becomes a waste of time.

There's a long way until that point however and in the meantime it's very easy for one to become complacent and thinking they know it all.

In order to be professionals, we the programmers must periodically challenge our notions.

Post reply on HN