Hacker News Reader

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.

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 reimplemented different bits of it in a thousand and one ways, nearly all of them more or less subtly broken. (I don't understand the obsession with JS library size - it's completely irrelevant in 95% of cases, compared to the megabytes of other garbage most sites will pull in for trackers and images).

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

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

You can. <input type="url" /> 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:

  <input type="text" validation="url1" autocomplete="url2" ...

I'm not sure how either of these would help:

- validation: Fundamentally, to be able to trust the input, the server needs to validate it in its final state. The only reason validation should be done on the client is to reduce the latency from the time the user inputs the data to the time the validation result is reported, so the user can fix their input faster if it fails validation. Sending it to a URL before form submit doesn't make sense when the input will have to be validated after form submit anyway.

- autocomplete: It's unlikely that implementing this in native code will be faster than in Javascript. It's not significantly faster to make an HTTP request in native code -- native code is more advantageous for heavy computation, graphics, and multithreading. And yet, it's easy enough to make HTTP requests from Javascript that an autocomplete attribute wouldn't add much value.

Being faster is not the point. Having to rely less on javascript libraries and more on the built in framework in the point.

And client side validation is not a substitute for server side validation, merely a better UX.

I have a library that attempts to improve the power of HTML:

http://intercoolerjs.org

Javascript library size matters a lot on mobile. If I'm recalling correctly, a huge app can take seconds just to be fully parsed on many phones. There are dozens of millions of people who are using budget android phones that do everything thing they need, but don't handle heavyweight pages super gracefully.

FWIW - The new ES2015 spec has a lot of features baked into the runtime which otherwise would have to be handled by underscore. - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Of course, its not exhaustive by any means. But your general everyday stuff is covered.

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/reading-a-plain-t... [1] http://stackoverflow.com/questions/326390/how-do-i-create-a-... [2] http://stackoverflow.com/questions/3402735/what-is-simplest-...

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.

What's wrong with

  new String(Files.readAllBytes(path));

or

  new String(Files.readAllBytes(path), StandardCharsets.UTF_8);

?

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.

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

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.

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.

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.

I disagree. I have been developing an IONIC application with JSweet. My experience is that when I want to refactor the code (for example, just renaming the data objects because the customer changes its mind about how to name something), then you are happy to have JSweet and you can make the code up-to-date in no time. The more the application gets complex, the better it is to have a transpiler to help you update your code safely. Your Faustian deal applies more to JavaScript IMO. It is very cool at the beginning, but at some point you start wondering what happens in your code and you need to write it again from scratch because it is not maintainable any more. JSweet is not GWT. It you don't like Java, try at least TypeScript and I am pretty sure you will change your mind.

I know nothing about JSweet but I have a 7-8 years of Java background and I can tell you right now that nothing in the Java world is a magic bullet.

But I am not here to argue specific examples. Sure, I definitely agree with you that Javascript is the worst offender in the transpiler world. I do however not see the connection between using a transpiler and having it easy when refactoring. If you mean that the transpiled language has an easier to parse AST and is thus much more prone to automated refactoring (Eclipse's "Rename Method" for example), I won't argue that; I know it can be true.

Nothing of what I said will stop me from trying Elm (transpiled to JS) for a hobby project though.

JSweet is not a magic bullet in the Java world, because JSweet is not Java. JSweet borrows the Java syntax to have well-typed JavaScript. Of course, not all transpilers have a focus on typing and not all of them have great tooling to back refactoring (not only renaming... you have plenty of other kind of help you will get when using a good Java IDE). But the focus of JSweet is typing and tooling (through Java).

I think that Christian Maioli Mackeprang is right. Some languages focus on instant productivity. They are really good and powerful to sketch a program in a few lines of code. But this quality comes at the expense of other important features that are really important for a language/development environment. People need to consider this or we will end up with poor programming environments and languages that are great for prototyping, but that don't scale up for complexity...

GWT is not a transpiler only. It is a framework. In GWT, the transpiler part is so little that it would be totally wrong to assume that transpilers are wrong because GWT is wrong. JSweet is like TypeScript. It just adds typing. No runtime, no lib, no framework, just a transpiler: I don't see any issues except if you consider that typing is an issue.

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