4 ms·

I can't speak to Vaadin, but adopting GWT was a huge mistake at my old company. We bought into the promise that you didn't need front-end developers or retrain

I can't speak to Vaadin, but adopting GWT was a huge mistake at my old company. We bought into the promise that you didn't need front-end developers or retrain on front-end tech, you can just use Java that you know and love! As it turns out, if you want to create a great front-end, you need to know javascript & css. You need to understand the difference between what is running on the client and what runs on the server. Corner cases which are super easy to fix with web-tooling turn into an impossible slog of trying to figure out how to get GWT do what you want it to do. GWT interfaces are famously brittle ugly huge monoliths that send a million AJAX requests that are almost impossible to debug or optimize. There are no separations of concern. There's no defined "API". It's like having nobody on your team know SQL and only ever use an ORM. At some point you need to break the layer of abstraction.

moasda 4y ago
Exactly. The abstraction is good to have quick first results. As soon as it comes to browser-specific issues or very detailed customer requirements you need the flexibility to look behind the abstraction layer. Then, if you do not have the necessary expertise, you are lost.
bunderbunder 4y ago
Also, GWT makes interacting with JavaScript libraries VERY painful. You have to go through a JNI-like FFI to do it. My take away from my time working in GWT is that the main thing it was trying to do is fundamentally misguided. It tried to make Web development more like desktop UI development by erasing the client/server boundary. But that’s a natural and important boundary that needs to be clearly visible. And, in its effort to do so, the project ended up also creating a new artificial boundary that isn’t helpful and shouldn’t exist. The problem isn’t writing client code in Java, BTW. There are plenty of projects like Elm that use the same language for both client and server code, and work well. The problem is trying to hide the Web behind a Swing-like API.
n00bskoolbus 4y ago
Agreed, this was the same pitch at my old job. "We can all keep writing Java and have a consistent front end". Which was true to some extent but we had very few people who were proficient with CSS/HTML so when we had to build out new components it always went to them or was time consuming for other people. They use React/Redux now and have a few dedicated front end teams.
morbia 4y ago
Exactly the same thing happened at my previous company... In particular, @GWTIncompatable made the leaking between frontend and backend an absolute nightmare. Their whole application was built on the idea that your models would be the same from the presentation layer all the way through to the database layer for 'DRY' reasons. It was horrible to work with and security was a disaster.
sixstringninja 4y ago
This. I had so much hatred for GWT, even as a backend developer. I remember how painful debugging was

moasda 4y ago

Exactly. The abstraction is good to have quick first results. As soon as it comes to browser-specific issues or very detailed customer requirements you need the flexibility to look behind the abstraction layer. Then, if you do not have the necessary expertise, you are lost.

bunderbunder 4y ago

Also, GWT makes interacting with JavaScript libraries VERY painful. You have to go through a JNI-like FFI to do it. My take away from my time working in GWT is that the main thing it was trying to do is fundamentally misguided. It tried to make Web development more like desktop UI development by erasing the client/server boundary. But that’s a natural and important boundary that needs to be clearly visible. And, in its effort to do so, the project ended up also creating a new artificial boundary that isn’t helpful and shouldn’t exist. The problem isn’t writing client code in Java, BTW. There are plenty of projects like Elm that use the same language for both client and server code, and work well. The problem is trying to hide the Web behind a Swing-like API.

n00bskoolbus 4y ago

Agreed, this was the same pitch at my old job. "We can all keep writing Java and have a consistent front end". Which was true to some extent but we had very few people who were proficient with CSS/HTML so when we had to build out new components it always went to them or was time consuming for other people. They use React/Redux now and have a few dedicated front end teams.

morbia 4y ago

Exactly the same thing happened at my previous company... In particular, @GWTIncompatable made the leaking between frontend and backend an absolute nightmare. Their whole application was built on the idea that your models would be the same from the presentation layer all the way through to the database layer for 'DRY' reasons. It was horrible to work with and security was a disaster.

sixstringninja 4y ago

This. I had so much hatred for GWT, even as a backend developer. I remember how painful debugging was