4 ms·

Is there any reason for a GWT developer to want to switch, either now or in future? Since GWT already provides all of those benefits with Java. The only reason

Is there any reason for a GWT developer to want to switch, either now or in future? Since GWT already provides all of those benefits with Java. The only reason for switching that I can see, is if Dart's performance becomes better. Edit: Also, for Java, you might wanna try an IDE like IntelliJ, which writes a lot of your code for you. Or Java 8, which makes things a -lot- less verbose.

spankalee 12y ago
First, I think GWT and the GWT team are awesome. They've created a great piece of technology that I've seen do some amazing things, especially with code sharing. But... I think Dart is just a much nicer language than Java. It's way more concise and quicker to prototype with due to dynamic typing. Dart also supports reflection, even though it's strongly discouraged for production it's great for getting starting on something very dynamic before writing Dart's equivalent of GWTs generators. Here's a few things I like better off the top of my head: - Types are optional - Fields and methods are in the same namespace, making tearoffs clean. - Getters and setters. No more getFoo() / setFoo() - Top level functions - Implicit interfaces. Every class also defines an interface. No more Foo / FooImpl just because someone _might_ want to implement, or just for tests. - Mixins - Constructor initialization is fixed - Named constructors - Named arguments - noSuchMethod() and Function.apply() - Lambdas and structurally checked function types (not every Java deployment has this yet) - No shared memory concurrency - Method cascades. - Better and more consistent core libraries. Fluent Iterable and Stream used everywhere. - Factory constructors - No more builder pattern (named arguments, factories, and cascades combine to make it not needed) - String interpolation - Operator overloading, including [] and ==. List and Map use [] and []=, not .get(), etc,. There's no .equals() you just override ==. - Source-code VM. Edit / refresh, and soon fix-and-continue hot swapping in dart2js. It adds up. If you look at a reasonably sized ported code sample, it _really_ adds up. It's not fun at all to go back to Java.
- aliakhtar 12y ago
  All the things you've mentioned involving dynamic typing, are not really a benefit. I much prefer the compile safety of strongly typed languages. GWT 2.7 has the same edit/refresh cycle, by the way (compiles have been optimized so they only take a couple of seconds). Lambdas and such are going to be added soon with Java 8 support.
  - spankalee 12y ago
    None of the things I mentioned involve dynamic typing. Care to elaborate?
    - aliakhtar 12y ago
      > quicker to prototype with due to dynamic typing. > optional types etc.
- solomatov 12y ago
  >Types are optional For me, this is show stopper which negates all other stuff. After types are optional, then type errors turn into warnings, and you get the same mess you have in JS. Another annoyance is lack of real generics.
  - spankalee 12y ago
    It's not the same mess as in JavaScript because we have checked mode which enforces the types at runtime. Combined with the static warnings we find this to be very, very effective. I hope you don't just leave warnings in your project :) but if during development you want to try some code path you're pretty sure will work while you have fixed up other paths that have warnings, you should be able to. The philosophy is to make as many errors happen at runtime rather than "compile" time so that you can continue to work with out always having to satisfy the type checker across your whole program. This is one of the productivity advantages of dynamically typed languages. We feel that the combination of dynamic types and checked mode gives you the best of both worlds.
    - aliakhtar 12y ago
      > The philosophy is to make as many errors happen at runtime rather than "compile" time This is pretty terrible. I would much rather find out about errors at compile time. Its a lot easier to find the source of the error from within the IDE and fix it, than to debug a runtime error.
      - SteveMcQwark 12y ago
        I can understand where you're coming from since I like static typing as well, but I don't think what you're saying is fair. It's good to be able to statically identify certain classes of errors so that you can, as you say, find and fix them within the IDE rather than having to resort to runtime debugging. What he (?) is saying is that, up until the point where you encounter the error at runtime, the fact that you can statically detect it shouldn't prevent you from running your code. This philosophy is obviously a tradeoff. It's good for prototyping since you don't have to make sure your whole program passes static analysis in order to test a particular code path. On the other hand, if developers get away with leaving such code in a large project (as a work in progress that never gets addressed, for example), this can create a maintenance nightmare. The solution to this is to not let people contribute code to the project which doesn't pass static analysis.

spankalee 12y ago

First, I think GWT and the GWT team are awesome. They've created a great piece of technology that I've seen do some amazing things, especially with code sharing. But... I think Dart is just a much nicer language than Java. It's way more concise and quicker to prototype with due to dynamic typing. Dart also supports reflection, even though it's strongly discouraged for production it's great for getting starting on something very dynamic before writing Dart's equivalent of GWTs generators. Here's a few things I like better off the top of my head: - Types are optional - Fields and methods are in the same namespace, making tearoffs clean. - Getters and setters. No more getFoo() / setFoo() - Top level functions - Implicit interfaces. Every class also defines an interface. No more Foo / FooImpl just because someone _might_ want to implement, or just for tests. - Mixins - Constructor initialization is fixed - Named constructors - Named arguments - noSuchMethod() and Function.apply() - Lambdas and structurally checked function types (not every Java deployment has this yet) - No shared memory concurrency - Method cascades. - Better and more consistent core libraries. Fluent Iterable and Stream used everywhere. - Factory constructors - No more builder pattern (named arguments, factories, and cascades combine to make it not needed) - String interpolation - Operator overloading, including [] and ==. List and Map use [] and []=, not .get(), etc,. There's no .equals() you just override ==. - Source-code VM. Edit / refresh, and soon fix-and-continue hot swapping in dart2js. It adds up. If you look at a reasonably sized ported code sample, it _really_ adds up. It's not fun at all to go back to Java.

aliakhtar 12y ago
All the things you've mentioned involving dynamic typing, are not really a benefit. I much prefer the compile safety of strongly typed languages. GWT 2.7 has the same edit/refresh cycle, by the way (compiles have been optimized so they only take a couple of seconds). Lambdas and such are going to be added soon with Java 8 support.
- spankalee 12y ago
  None of the things I mentioned involve dynamic typing. Care to elaborate?
  - aliakhtar 12y ago
    > quicker to prototype with due to dynamic typing. > optional types etc.
solomatov 12y ago
>Types are optional For me, this is show stopper which negates all other stuff. After types are optional, then type errors turn into warnings, and you get the same mess you have in JS. Another annoyance is lack of real generics.
- spankalee 12y ago
  It's not the same mess as in JavaScript because we have checked mode which enforces the types at runtime. Combined with the static warnings we find this to be very, very effective. I hope you don't just leave warnings in your project :) but if during development you want to try some code path you're pretty sure will work while you have fixed up other paths that have warnings, you should be able to. The philosophy is to make as many errors happen at runtime rather than "compile" time so that you can continue to work with out always having to satisfy the type checker across your whole program. This is one of the productivity advantages of dynamically typed languages. We feel that the combination of dynamic types and checked mode gives you the best of both worlds.
  - aliakhtar 12y ago
    > The philosophy is to make as many errors happen at runtime rather than "compile" time This is pretty terrible. I would much rather find out about errors at compile time. Its a lot easier to find the source of the error from within the IDE and fix it, than to debug a runtime error.
    - SteveMcQwark 12y ago
      I can understand where you're coming from since I like static typing as well, but I don't think what you're saying is fair. It's good to be able to statically identify certain classes of errors so that you can, as you say, find and fix them within the IDE rather than having to resort to runtime debugging. What he (?) is saying is that, up until the point where you encounter the error at runtime, the fact that you can statically detect it shouldn't prevent you from running your code. This philosophy is obviously a tradeoff. It's good for prototyping since you don't have to make sure your whole program passes static analysis in order to test a particular code path. On the other hand, if developers get away with leaving such code in a large project (as a work in progress that never gets addressed, for example), this can create a maintenance nightmare. The solution to this is to not let people contribute code to the project which doesn't pass static analysis.