Video details

How Should Java Developers Build Front-Ends for Web, Mobile, and Desktop Today? by Karsten Silz


For more info on the next Devoxx UK 👉
Users access applications on PCs and mobile devices today. There are two obvious ways to build front-ends for these devices: Web applications and native applications. Cross-platform UI frameworks combine advantages from both approaches. Examples are Google’s Flutter, JavaFX, Facebook’s React Native, and Microsoft's Xamarin. Important web application frameworks are Google's Angular, Facebook's React, and Vue.js. I will look at all these toolkits from the perspective of a Java developer and suggest which one to use in three common scenarios: New web application, new native iOS & Android apps, and what to do on the desktop when we have a web application.
In 2019, I developed a mobile app prototype with Flutter and a progressive web application prototype. I then decided to use Flutter for native mobile apps in my SaaS start-up. Based on my experiences, I will highlight what's good about Flutter and what's not.


Hello. Welcome. My name is Kasten and I want to talk about how should Java developers build front ends for web, mobile and desktop today? If you have any questions, please use the Rocket platform to post them there as well, because the remote guys are going to use that as well. So for slides and more, you can either go to this link or you can just take a picture of this QR code. You also find that in the session page that link, so you find more stuff there. That's why I'm going to move on from this slide. So what's on the agenda today? It's really just four points. Number one is I want to build a wish list for Java developers on how we would like to build font. Then I'm going to talk about how we can build new web applications, how we can build new native mobile apps. And finally, when we have a web application, what are we going to do on the desktop? Now you may ask yourself, well, why should we listen to this guy here? So I've been a Java developer for 22 years, and I recently put three full stack Java projects into production. I'm a reporter in Fuqu, so I've got some idea what's going on in the software world. I use twelve criteria to judge these frameworks that I'm going to be talking about. I'm not trying to sell you anything here. I'm not affiliated with any of these projects. And for full disclosure, and my current project, I'm using Angular and Flutter. But no matter what I tell you here today, in the end you decide it's your decision, right? I just help you hopefully make this decision. So let's get started with this wish list. What are we actually talking about? What kind of applications am I talking about? I mean, with Java developers, which means it's enterprise applications, reports, forms, data, quits this kind of stuff. So we're not talking about media applications or games or any of that stuff. Now with devices, it's the enterprise. So we've got PC, Windows, Mac, and Linux, and we've got increasingly mobile devices. But now coming to that wish list, I told you that I've got twelve criteria. And here we go. The first one is, of course, Java. When we build front ends, we would like to use Java, we'd like to use state of the art. I'll explain that in a second. We want to pick an option that's safe. I also explain that in a second. And I also explain what I mean with Popular. Now we want to build web applications, we want to build mobile applications, we want to build desktop applications, we want to have many libraries so that we don't have to write the code all ourselves. We want to put create fast applications that have access to the native functionality of the devices that they're running on. We want to use one code base for all of that. And we want to have a fast build deploy in the bug. I mean, nobody likes to wait for the compiler, right? So let's talk about state of the art. Why is state of the art important? It's because it makes it easier to change from framework A to framework B if both use the same high level principle. So makes it easier to change. What is the state of the art? Declarative declarative means three things. Number one is you create your eye as code, so it's not visual tools anymore where you drag and drop elements. No, you write code. Your components communicate with each other through status and events indirectly. And the framework drives the update on the talk page, the one, the link that I gave you. You can find an example of that, and you find also code examples of what this looks like. So StateoftheART is declarative. Let's talk about safe. Safe really means the framework, the technology is still here five years from now. So that's a judgment call on my side or on your side. And finally, Popular. Why do I care about popular? Well, Popular makes our life easier in three ways. It makes it easier to learn the technology because there's more material out there to learn, makes it easier to code because there are better tools and more tools out there. And finally, it makes it easier to roll it out because it's easier to hire developer and to get management buy in. Okay. How do we measure popularity? How did I measure popularity? You can find it on the page. I used Google Searches. Look how many students at Udemy learn a certain technology. I looked at how many stack overflow questions there are, and I analyzed job ads in 63 countries to figure out what technology is popular. And you can find all of that on the top page. So this is my wish list. So let's sum up. We want to build enterprise applications for PC and mobile. We just saw our wish list. The state of the art is declarative, and we want to measure popularity. So that was the first item of the agenda. Now, onto the web application. What kind of frameworks do we have? It's three, the big three that you stumble across there. Number one, it's Angular from Google, React from Facebook and Vuegs. There's a couple that I eliminated. You find them on the talk page, including avoiding. For instance, that's one of the examples that I don't include in here. So let's score them based on our wish list. Now, not all of them apply to web application. So Java, the Angular to me is the winner because Angular uses TypeScript and TypeScript is closer to Java than poor JavaScript. Declarative Reactive is Declarative. Angular is not, at least not out of the box. I think it's a little more likely that React is still going to be around. Google has that tendency to kill projects. You also see that React is more popular in all of those four metrics that are listed. As far as creating the web applications that we need, I think all three of them are capable of doing that. So that's a draw for libraries. I'm not sure which one has the most libraries. I guess it's a draw because typically the major libraries at least are available for all three frameworks. React produces the fastest applications. They've got some special stuff for Loading components concurrently. You find that on my Talk page, and I'm not sure which one has the fast build and deploy, but they often have the same components like Webpack for building or NPM. So I think it's probably a draw. Now if we kind of sum it all up and we say, hey, the winner on the web is React, Angular is second and UGS is third. So what's my advice here? My advice is that if you use any of these three technologies, React angle of you keep it on your current project. Otherwise you could think about migration. Now, migration rarely ever makes business sense, but in the case that you do migrate or you start a new project, I would recommend that you start with React first, then Angular, and then View. This concludes the Web part. Now on to mobile applications. Question is, how can we actually build mobile applications on these phones? There are two obvious ways of doing that. The first one is we build a web application that runs on both, or we build two native applications. If we see what are the advantages of these two approaches, and we see that on the Web, we have one code base which we like. That was the goal that we have. And on the native side, we have fast applications with all the features and a good debugging debugging on mobile devices sucks. Now if we look at all these advantages, isn't there a way that we could somehow combine them into one? And yes, there is. There's cross platform frameworks. I'll be talking about two. In this talk that I looked at in detail, I limited two again. Among them is JavaFX, so I didn't take that into consideration. So the two again, we've got Google and Facebook squaring off again, Google with Flutter and Facebook with React native. Now what's Flutter? In the words of Google, you can find it up here and give you a moment. So Google is really audacious here. They want to create beautifully natively compiled applications for mobile, web and desktop from a single code base. Write once, run everywhere. We know it's Java. Guys, that sounds easier than it really is. My experience with Flutter is from a Cat sitter app that I built. You can find it in the app store. It's still enclosed better, but that's what it looks like. So you've got a list of visits that you can see, and then you've got some details and some actions on those visits. And then here's my Cat Max. He's in the app. So Yay Max. So you can find a deep dive on Flutter with details in the talk page. Here's just the summary. So what did I like about Flutter? Flutter uses Start, which really is a simplified Java customized for building UIs. It allows for simple native integration, access to pictures and camera and stuff is easy. The code build and deploy is fast. You press save and within a second you've got your changes running on a device or your simulator. I've got a video on the talk page. You can look at it really good and the plugins save a lot of time. Now what's not so good about Flutter is number one, everybody is going to ask you, when will Google kill Flutter? Because Google kills a lot of projects that's at least annoying. You cannot really build a single application from one codebase and runs on desktop, web and mobile. And you can see the reasons in my talk page. The responsive design is a bit too simple for me. It really isn't a good solution and building really native looking applications is too time consuming. That should be easier, but it is. But you can get around then. So now with all of that out of the way, and again, the deep dive is on the talk page. Let's score these two frameworks, React native and Flutter for mobile. These don't apply for our native stuff. So Flutter wins on the Java side because that really is very close to Java and they're both declarative. So that's the draw. React native. Again, I'm a bit more certain that this is still around compared to the Google framework. So React wins here. React loses on three out of those four popularity criteria, but it has more jobs worldwide. Has about twice as many jobs for React native than for Flutter in the UK is even worse. I think it's like three times as many. So that's why I think React is more popular. Both can build the kind of business applications that we need. Not so sure about which one has the most libraries. Probably you draw. Flutter creates faster applications. It's also easier to get access to native functionality with Flutter. Both have one code base, so a draw again. And for build, deploying the bug. I think it's probably a draw, but you can really get used to that pressing save and then a second later having the changes running in your code. So who's the winner? Flutter, to me is the winner and React native takes on second price. And that's a case where maybe you decide differently. Remember I told you at the beginning you need to make your own decision. Maybe you say for you, React Native is the winner because there are more jobs. You say I can't find developers, so I better go with React native. So what's my advice on your existing project? If you use any of those two frameworks, keep them if not, think about migration. But again, migration rarely ever makes sense. If you start a new project and have used React before or you do migrate and start with React native and then use Flutter. Otherwise it's the other way around. Flutter first and then React native. Okay, so now the two minutes and we got to get to the desktop. But Desktop is going to be short. Why? Because there's really no good option. There's no good cross platform option. And even if you want to build native applications, there's lots of change there, right? I mean, Microsoft just got Windows Eleven out there. Apple did a design language change a year ago or two, and they're still transitioning in their tools. So it's difficult to build Desktop application. But really the killer criteria is the kicker is that our customers, enterprise users, they are used to using web application because that's most of the applications to access our web applications. Which is why I'm telling you, keep your web application. Don't try to build a desktop application, except for if you can stomach the UI restrictions that Flutter gives you, which in essence means your desktop application is going to look more like a web application. Again, look at the deep dive on my talk page. Then you could evaluate Flutter for desktop. That means we're now at the summary where I'm going to tell you again what I already told you. So in case you dosed off after lunch session for the Web, keep React Angular or View Migration probably doesn't make sense off of anything else for a new project or if you do migrate, React first, angle next and then UJS last. For mobile, keep Flutter React native. And if you start a new project and have used React before, use React native, then Flutter. Otherwise it's the other way around. And for Desktop, we just saw that. Keep your web application unless the Flutter constraints are okay with you, and then you can evaluate it for the desktop. Now, before I wrap up, here's a little Advertisement. I'm looking for a project starting May 22. I'm a full stack developer, contractor, fixed term, employee kind of thing. That's what I'm looking for. Milton Keynes, London or Remote. And that marks the end of my talk. And here you can find the slides, videos, opportunity to give me feedback. The deep dive that I was talking to you about, all of that is available here. You can also find the URL on my Talk page on the conference site. Thank you. Okay, so the question was, what about Kotlin? That's right. So Kotlin, in case you're not aware, on the Android side, we've got Jetpack Composed, which uses Kotlin to build Android applications. And then there's something called Kotlin for web and Kotlin for Desktop. Number one, this is still a very early solution. And number two, there's a gaping hole in there, which is iOS. As far as I'm aware, you can use Jetpack compose which is a Google product, to build your Android app. Then you can use jetpack for compose for web and desktop which is from JetBrains the IntelliJ IDE guys to build for web and desktop but there is nothing to build on iOS so you have at least a native iOS application plus all the other stuff. That's why I think it's not a valuable solution right now because I think when it comes to mobile you either build a web page or you build two native applications. We've got applications for both platform but if you need to use iOS native and then something else then I would say then rather go for react, native or flutter because they get both with one codebase. I hope this answered your question. It did not. I haven't actually experienced that. So the question is about what about flutter build times they become really large. I haven't experienced that number one. In mobile development, build times are generally pretty long. It could easily take a minute or two for just native iOS. Okay, so the size of the application that's coming out of it, the application that I built, the one that you saw is about 40 megabytes on Android and I think like 50 or so on iOS. I don't think they're that huge anymore and I've got the number of libraries so I think in this day and age usually whether your app is like 70 or 80 megabytes is not that much of a big deal. To me it wasn't an obstacle and I know they're saying that they're working on reducing the size but to me it wasn't bad. I didn't create an overly large application so to me it was fine. Okay. Nobody has any questions. Thank you and please enjoy the next sessions and the rest of the conference.