5 ms·

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 t

by vivin 10y ago

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 artifact, and then how to release and publish it; the barrier of entry is much higher because there is a lot more to learn and understand. The article mentions Android - I haven't worked much with Android and so I'm not familiar with the libraries there. Is there the same sort of problem in the Android ecosystem that you see in Node? I wonder if he is talking about the fragmentation of Android implementations (flavors from different providers), which is a different thing entirely. Seeing as Android uses Java, I'm thinking the ecosystem is not like Node.

ourmandave 10y ago
That's why there's JSweet, the Java to Javascript transpiler. http://www.jsweet.org/ http://www.jsweet.org/
- mooreds 10y ago
  Transpilers have their own issues. Source: I spent years developing with GWT
  - jmiserez 10y ago
    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.
  - pdimitar 10y ago
    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.
    - renaudpawlak 10y ago
      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.
      - pdimitar 10y ago
        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.
        renaudpawlak 10y ago
        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...
  - renaudpawlak 10y ago
    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.
- jmiserez 10y ago
  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 https://jazz.net/wiki/bin/view/Main/JDojo Twitter: https://twitter.com/jdojo https://twitter.com/jdojo
branchless 10y ago
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++.
cm2187 10y ago
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.
- douche 10y ago
  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).
  - cm2187 10y ago
    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.
    - carsongross 10y ago
      I have a library that attempts to improve the power of HTML: http://intercoolerjs.org http://intercoolerjs.org
    - 10y ago
stevesun21 10y ago
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.

by vivin 10y ago

ourmandave 10y ago

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

mooreds 10y ago
Transpilers have their own issues. Source: I spent years developing with GWT
- jmiserez 10y ago
  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.
- pdimitar 10y ago
  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.
  - renaudpawlak 10y ago
    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.
    - pdimitar 10y ago
      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.
      - renaudpawlak 10y ago
        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...
- renaudpawlak 10y ago
  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.
jmiserez 10y ago
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 https://jazz.net/wiki/bin/view/Main/JDojo Twitter: https://twitter.com/jdojo https://twitter.com/jdojo

branchless 10y ago

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

cm2187 10y ago

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.

douche 10y ago
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).
- cm2187 10y ago
  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.
  - carsongross 10y ago
    I have a library that attempts to improve the power of HTML: http://intercoolerjs.org http://intercoolerjs.org
  - 10y ago

stevesun21 10y ago

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.