JavaFX vs. HTML5(번역)

JavaFX vs. HTML5

2014년 10월 29일

리치 클라이언트 기술을 선택하는 것은 매우 어려운 일이다! 나는 최근에 JavaFX와 HTML5 간에 선택이 필요한 회사에 몇번의 컨설팅을 한적이 있다. 이 글에서 나는 이 주제에 대해서 나의 몇몇의 통찰을 공유하려고 한다.

I don't intend this to be a battle between technologies by making one win over another. It really depends on your situation. But this article can give you some criteria to keep in mind when you make your choice.

나는 이것을 한쪽이 다른 쪽에 이기는 기술간의 전쟁이되는 것을 바라지 않는다. 그것은 정말로 여러분의 선택에 달려있다. 하지만 이 글은 여러분에게 여러분이 선택할때 명심해야 할 몇몇의 기준을 줄수 있을 것이다.

I know that by sharing all this information here for free it'll be less likely that people will need my consulting advice. So, if this article is a help to you and saves you a lot of work and time, consider supporting me. This will help me provide more free resources like this.

나는 여기서의 모든 정보가 공짜로 사람들이 나의 컨설팅 조언이 덜 필요할 수 있다는 것을 알고 있다. 그래서, 만일 당신이 여기서 당신의 많은 시간과 노력을 줄이는데 도움이 되었다면, 나를 지원 하는것을 고려해 보라. 이것은 내가 이와 같은 더 많은 공짜 리소스를 제공하는데 도움이 될것 이다.

Target Audience

대상 청중들

A lot of Java developers are asking themselves if they should adopt JavaFX for their next user interface or make the switch to an HTML5 technology. I know and love both worlds. I've been using JavaFX since early 2012. Lately I've mostly been programming web applications and will continue to do so in the coming months.

많은 자바 개발자들이 그들의 다음 사용자 인터페이스를 JavaFX로 채택할지 혹은 HTML5로 교체 할지를 스스로에게 묻고있다. 나는 양자의 세계(JavaFX, HTML5)를 알고 있고 좋아한다. 나는 JavaFX를 2012년 초반 부터 사용해왔다. 최근에 나는 대부분 웹 어플리케이션 프로그래밍을 해왔고 앞으로 계속 그러 할 것이다.

I'm not talking about small projects that can be implemented as simple websites with a little interactivity. This article is about rich client applications with a lot of interactive elements.

나는 작은 상호작용으로 구현되는 단순한 웹사이트와 같은 작은 프로젝트에 대해서는 언급하지 않을 것이다. 이 글은 상호작용이 많은 리치 클라이언트 어플리케이션에 대한 것이다.

내용 테이블

Here is a list of the criteria that we will look at:

아래는 우리가 살펴볼 목차이다.

Then we finish off with:

그런 후에 우리는 아래와 같이 끝맺을 것이다.

Richness and Aesthetics of UI

UI(사용자 인터페이스)의 리치(풍부함)와 미학

JavaFX

JavaFX comes with a decent default theme called Modena.
The theme is easily customizable with CSS.
There are many UI widgets (scroll down to "All controls in Modena"). It comes with complex widgets and interactions out of the box: TreeTableView, TextFlow (supports rich text), DatePicker, Charts, 3D support, WebView (with a modified Webkit engine), Drag and Drop, and more.
If you need more widgets there is the excellent ControlsFX project and also JFXtras.
JavaFX also comes with a nice visual designer called JavaFX Scene Builder which I like a lot.

JavaFX

JavaFX는 Modena라는 괜찮은 기본 테마로 되어있다.
테마는 CSS로 쉽게 커스터마이징 할 수 있다.
많은 UI widget(위젯) 들이 존재한다.(아래의 "Modena의 모든 컨트롤"로 이동해보라). 그것들은 훌륭하고 복잡한 widget들과 상호작용들이다 : TreeTableView, TextFlow(Rich 텍스트를 지원하는), DatePicker, Chart, 3D지원, WebView(Webkit엔진을 수정한), Drag and Drop, 그리고 그 이상.
만일 여러분이 더많은 Widget이 필요하다면, 매우 훌륭한 ControlsFX 프로젝트와 또한 JFXtras라는 프로젝트가 존재한다.
JavaFX는 또한 훌륭한 Visual 디자이너이자 내가 많이 좋아하는 JavaFX Scene Builder가 있다.

HTML5

I guess (almost) everything is possible with HTML5.
The options of libraries and frameworks are immense.
HTML5 targets many browsers and all possible screen sizes. This is great but it is also very difficult to implement one clean solution that works everywhere.
Complex widgets (like tree-tables) are hard to implement.
Complex interactions with good performance are hard to implement. I've had my share of experiences by writing a drag and drop library!

HTML5

나는 아마도(거의) HTML5로 모든 것이 가능하다고 추측한다.
라이브러리와 프레임워크들의 선택사항이 방대하다.
HTML5는 많은 브라우저와 가능한 모든 화면 사이즈를 목표로 한다. 이것은 대단한 것이다, 하지만 어디에서나 동작하는 하나의 깔끔한 솔루션으로 구현하기 또한 어렵다.
복잡한 Widget들(tree-tables와 같은)은 구현하기 힘들다.
좋은 성능으로 복잡한 상호작용을 구현하기 힘들다. 나는 나의 경험을 drag and drop library에 공유해 놓았다.

Result

Since JavaFX mainly targets the desktop and HTML5 all possible screen sizes, it is not really fair to compare the two in terms of richness and aesthetics of UI.

With JavaFX you will not have to think a lot about UI widgets and interactions. You get everything out of the box. So, if you're implementing a larger business application you will certainly get nice results much faster and easier with JavaFX.

결과
JavaFX의 주된 대상은 데스크탑과 모든 가능한 화면 사이즈의 HTML5이기 때문에 양자는 UI의 풍부함(리치)과 미학적으로 볼때 정말로 공평한 비교가 아니다.

JavaFX에서 여러분은 UI Widget(위젯)이나 상호작용에 대해 많이 생각하지 않아도 될 것이다. 여러분은 모든것을 탁월하게 할 수 있다. 그래서, 만일 여러분이 큰 비즈니스 어플리케이션을 구현한다면, 여러분은 확실히 JavaFX로 더 빠르고 쉽게 훌륭한 결과를 얻을 것이다.

Options for Mobile and Tablet

모바일과 타블렛을 위한 옵션

JavaFX

JavaFX is mainly for Desktop use. JavaFX for Android/iOS is a community effort. There is currently no official support by Oracle.

JavaFX Ports - website about the current state of JavaFX ports to different platforms.
Is it possible to run JavaFX applications on iPhone/Android/Win8 mobile? - good collection of links.

JavaFX는 주로 데이크탑용으로 사용한다. 안드로이드와 iOS를 위한 JavaFX에 대한 커뮤니티의 노력이 있다. 현재 Oracle(오라클)의 공식적인 지원이 없다.

JavaFX Ports - 서로다른 플렛폼에 대한 JavaFX ports의 현상태에 대한 웹사이트
JavaFX 어플리케이션이 iPhone/Android/wind8 mobile에서 구동 가능한가? - 유용한 링크 모음.

HTML5

Targetting mobile and desktop browsers there is no limit for HTML5. But to create a larger application that works accross many different screen sizes is everything but trivial both from a design and from a technical perspective.

모바일과 데스크탑 브라우저를 대상으로 HTML5는 제약이 없다. 많은 다른 사이즈의 화면 크기들로 작업하는 큰 어플리케이션을 위해 디자인이나 기술적 조망이 하찮은 것이다.

Result

Obviously, HTML5 is the winner here.

I haven't tried any of the JavaFX ports for mobile but from what I've seen they don't seem to be production ready, yet. Through community effort this might change in the near future and could actually be usable. So, definitely create some prototype to see if you can use it.

결과
여기서는 명백하게 HTML5의 승리이다.
나는 모바일을 위한 JavaFX ports에 대해 어떠한 노력도 하지 않았고 그들의 제품도 아직은 준비되어 있지 않은 걸로 보인다. 커뮤니티의 노력으로 머지않은 미래에 이는 바뀔것이고 실제적으로 사용할 수 있을것이다. 따라서, 여러분이 사용할 수 있는 프로토타입의 몇몇은 만들어져있다.

Learning Curve

학습 곡선

JavaFX

When you're a Java programmer and you've created some Swing GUIs, learning JavaFX will be straigt forward. As a Java Swing developer you should be excited by the new possibilities of JavaFX.

If you work through my JavaFX 8 Tutorial you will get familiar with the most important concepts of JavaFX and even some new Java 8 language features:

Separating the presentation layer with FXML and SceneBuilder (you can also create JavaFX applications in Java code completely, if you want).
Using the new Properties classes and ObservableLists for automatic UI updates.
Working with the TableView.
Using CSS for styling.
Creating charts.
Deployment.

JavaFX

여러분이 Java 프로그래머이고 몇몇의 Swing GUI들을 만들때 JavaFX를 배우는 것은 앞으로 나아가는 것이다. Java Swing 개발자로서 여러분은 JavaFX의 새로운 가능성에 흥분할 것이다.

만일 여러분이 나의 JavaFX 8 튜토리얼을 통해 일하고 있다면 여러분은 JavaFX와 Java 8언어의 새로운 몇몇의 특징의 가장 중요한 개념에 익숙할 것이다.

FXML과 SceneBuilder의한 분리된 프리젠테이션 계층(여러분이 원한다면, 여러분은 순수 Java 코드로 JavaFX 어플리케이션을 만들수 있다.).
자동화된 UI 업데이트를 위한 Properties클래스와 ObservableList들의 사용
TableView 작업
스타일을 위한 CSS의 사용
차트의 생성
배포

HTML5

For a Java developer it is quite difficult to make the switch to HTML5. I know because I've gone that route and it has taken me more than two years to really feel comfortable with the web platform and the various web technologies.

Java 개발자들에게 HTML5로의 전환은 꽤 어려운 어려운 일이다. 나는 내가 그러한 경로를 갔기 때문에 그 이유를 알고 있고 웹플렛폼과 다양한 웹 기술에 익숙하기위한 2년 이상을 보냈다.

Here are some reasons that make it difficult for experienced Java developers to learn HTML5:

Many browsers with differing behaviors (Chrome, Firefox, Safari, mobile Safari, different versions of Internet Explorer, etc.)
Must learn HTML: This is the easiest part.
Must learn CSS: Not too hard to understand the general concepts but very difficult to work with in larger projects. It gets you in a big mess if not done right (no encapsulation!). And making the styles work across many browsers is a great challenge. You'll end up using some CSS pre-processor like SASS or LESS which adds one more thing you need to learn.
Must learn JavaScript (there are alternatives though):

No static types: This is difficult to grasp for a Java developer.
Tool support: Because there are no static types the IDE can't help you much with content assists.
No real classes: Prototype-based programming.
JavaScript oddities: A lot has been said about that.
You will end up using a framework or two which is yet another thing to learn.
JavaScript itself is ok, but difficult to get right.

아래에 능숙한 Java 개발자들이 HTML5를 배우기 어려운 몇가지의 이유가 있다:

많은 브라우저에서 다르게 동작한다(Chrome, Firefox, Safari, mobile Safari, 다른 버전의 Internet Explorer, 등등)
반드시 HTML를 배워야한다: 이것은 쉬운 부분이다.
반드시 CSS를 배워야 한다: 일반적인 개념을 이해하는 것은 어렵지 않지만 큰 프로젝트에서 사용하기 매우 어렵다. 재대로 사용하지 않으면 큰 혼란에 빠진다.(캡슐화 없음!) 그리고 많은 브라우저를 통한 스타일을 많드는 것은 큰 도전이다. 여러분은 SASS 혹은 LESS와 같은 몇몇의 CSS pre-processor를 사용하여 작업을 끝내게 되는데 그것은 여러분이 배울 필요가 있는 또하나의 추가사항이다.
반드시 Javascript를 배워야 한다(대안적 이지만)
static 타입이 없다: 이것은 Java 개발자가 이해하기 어렵다.
Tool지원: static 타입이 없기 때문에 IDE(개발환경)가 여러분에게 content assist로 도울 수 없다.
Javascript의 이상함: 이것에 대해서 많이 이야기 해왔다.
여러분은 하나 framework 혹은 익혀야 할 다른 framework를 사용하여 작업을 끝낼것이다.
Javascript 자체는 OK 이지만, 정확히 사용하는 것은 어렵다.

I think it takes quite some time but it is possible for Java developers to make the switch to HTML5 if they are excited about learning new web technologies.

Java 개발자들이 새로운 Web 기술에 흥미있다면 HTML5로 전환할 수 있을 것이지만 내 생각에 그것은 꽤 오랜시간이 걸릴 것이다.

But it will be really difficult for unexperienced web developers to create a well architected and maintainable project. It takes a lot of experience and discipline to stick to good practices in JavaScript projects. If the project is fairly large and multiple developers are working on the same web client it's easy to end up in a mess.

하지만 그것은 경험없는 Web 개발자가 잘 설계되고 유지될 수 있는 프로젝트를 만드는 것은 정말로 어려울 것이다. 그것은 Javascript 프로젝트에서 좋은 연습으로 많은 경험과 훈련을 필요로 한다. 만일 프로젝트가 꽤 크고 복수의 개발자가 같은 Web 클라이언트로 일한다면 그것은 엉망으로 끝나기 쉽다.

Because many larger organizations have experienced those problems they created their own solutions to tackle them. In my opinion, the best approach so far is Dart. Dart is an open source language developed by Google that provides a very nice and fresh but still familiar language. It comes with lots of libraries and tools that make developing large web application much easier. And, of course, it compiles to JavaScript so it can be used everywhere.

많은 큰 조직들이 이러한 문제를 경험했기 때문에 그들은 그것들을 다루기 위해 자신들의 솔루션을 만들었다. 내 의견으로는, 지금까지 가장 좋은 접근은 Dart이다. Dart는 구글에서 개발된 Open Source 언어로 매우 훌륭하고 신선하고 익숙함을 제공한다. 그것은 많은 라이브러리와 툴들로 되어있고 더 큰 Web 어플리케이션을 쉽게 개발할 수 있도록 한다. 물론 그것은 어디서든 사용할 수 있게 Javascript로 컴파일 한다.

The other web technology I can recommend is Web Components which I believe is the primary way how we will develop for the web in the future. Web Components enable real encapsulation of HTML, CSS and JavaScript (or Dart) so they don't interfere with the rest of the page. Nicely encapsulated, the UI widgets are reusable as components anywhere in your application. Web Components is an evolving standard but it isn't implemented in all browsers yet. It's still early days but you can use it today with the polyfill libraries polymer or x-tags. If you're using Dart instead of JavaScript there is Polymer.dart.

내가 추천하는 다른 Web 기술은 Web Components인데 나는 그것이 우리가 미래에 Web을 개발하게 되는 주요한 방법이라고 믿는다. Web Components는 HTML, CSS와 Javascript(혹은 Dart)의 리얼 캡슐화가 가능해서 그것들은 페이지 여분을 망치지 않는다. 멋지게 캡슐화 되어, UI Widget들은 여러분의 어플리케이션에서 컴포넌트로 재사용이 가능하다. Web Component는 진화하는 표준 이지만 아직 모든 브라우저에서 구현되어 있지 않다. 아직까지는 초창기지만 여러분은 현재 polyfill 라이브러리인 polymer혹은 x-tags를 사용할 수 있다. 여러분이 Javascript 대신 Dart를 사용하고 있다면, Polymer.dart가 존재한다.

Result

For Java developers it is quite a large step until they will be able to design reasonable web applications. Migrating a larger Swing application to HTML5 without experienced web developers would entail a significant risk of failure.

JavaFX is the obvious winner concering the learning curve if your primary background is in a non-web language like Java, C#,... If you're already comfortable with web technologies or you're excited to learn something new I recommend you give Dart a try.

결과
Java 개발자들에게 그들이 합리적인 Web 어플리케이션을 디자인 할 수 있도록 하는 것은 꽤 큰 발걸음이다. 경험있는 Web 개발자 없이 큰 Swing 어플리케이션을 HTML5로 변환하는 것은 실패의 중요한 위험을 수반하는 것이다.

여러분의 주요배경 언어가 Java, C#...과 같이 Web 언어가 아니라면 학습 곡선을 고려할 때 JavaFX가 명백한 승자이다. 만일 여러분이 이미 Web 기술에 편안하거나 새로운 것에 흥미를 느낀다면 나는 여러분에게 Dart를 시도 할 것을 추천한다.

Long-term Support

장기간 지원

JavaFX

JavaFX is now part of JRE/JDK for Java 8.
Oracle says: JavaFX replaces Swing as the new client UI library.
Java is huge and when used on the client, JavaFX is now the default.
JavaFX is open source

JavaFX

JavaFX는 Java 8의 JRE/JDK의 현재 파트가 존재한다.
오라클의 언급: 새로운 클라이언트 UI 라이브러리로 JavaFX가 대체 할 것이다.
Java는 방대하다. 그리고 클라이언트로 사용에서, JavaFX가 현재 기본이다.
JavaFX는 오픈소스(Open Source) 이다.

HTML5

HTML5 is here to stay. But for a business application of significant size you will need to rely on third-party frameworks, tools and maybe even languages. Just a quick, more-or-less random selection of choices you will likely encounter:

HTML5는 여기에 머물러있다. 하지만 중요한 크기의 비즈니스 어플리케이션을 위해 여러분은 Third-Party 프레임워크나, 도구, 언어에 조차 의지해야 할 것이다. 단지 빨리, 많거나 적거나 임의의 선택들을 여러분은 마주칠 것이다.

HTML manipulation, event handling, animations, ajax	jQuery
JavaScript MVC Framework	angular.js (Google), ember.js, backbone.js, react.js (Facebook), etc.
Languages to improve or replace JavaScript	CoffeeScript, TypeScript (Microsoft), Dart (Google), etc.
CSS frameworks:	Less, Sass, etc.
UI Components	jQuery UI, Bootstrap (or similar), some charts library, Web Components, etc.

The lifecycle of web frameworks and tools is quite short. When relying on many third-party libraries and tools you will need to track all the changes and you can only hope that support and updates will continue.

Also, browsers are changing fast, so you might need to keep up with those changes.

Web 프레임워크와 툴들의 생명주기는 꽤 짧다. 많은 Third-Party 라이브러리와 툴들에 의지하고 있을때 여러분은 모든 변화를 추적할 필요가 있고 여러분은 단지 기술지원과 업데이트가 계속 될 것을 희망해야 한다.
또한, 브라우저의 변화는 빠르고, 그래서 여러분은 아마도 그러한 변화를 계속 유지해야 할 것이다.

Result

It's difficult to predict the future here: Who can say what happens to Oracle, Google, Facebook, etc. and to any of the Web Frameworks in a few years.

Even though it might decline in favor of some new and fancy languages, I believe Java will still be with us for quite some time to come. With JavaFX you get almost everything you need for your UI from one single source and you know you can rely on it to stay stable for quite a while. Since JavaFX is open source this at least gives you some confidence that an open source community could provide support even if Oracle wouldn't.

Concerning web technologies: I presume that we will continue to see some major shifts in web technologies. These are my guesses for web technologies in a few years:

As browsers and languages evolve we will not use jQuery any more.
JavaScript will still be around but I believe it will mostly be used as a compile target and not as a language to write large web applications with. Languages like Dart, CoffeeScript, TypeScript, and AtScript are the alternatives.
I believe Web Components will pretty much replace most web frameworks.

Since it's really difficult to tell where the HTML5 trends are heading, I'd currently favor JavaFX when it comes to long-term support.

결과

미래를 여기서 예측하는 것은 어려운 일이다: 오라클, 구글, 페이스북에 어떠한 일이 일어날지 누가 이야기 할 수 있고 몇년내에 Web 프레임웍에 어떤일이 일어날지 누가 이야기 할 수 있을까? 몇몇의 새롭고 화려한 언어의 유행이 쇠퇴함에도, 나는 Java가 꽤 한동안 우리와 함께 할 것이라고 믿는다. JavaFX와 함께 여러분은 하나의 소스로 여러분의 UI의 요구의 모든것을 얻을 수 있고 여러분은 그것이 오랜동안 안정적으로 될것이라는 것을 알고있다. JavaFX는 오프소스이기에 적어도 여러분에게 오픈소스 커뮤니티의 지원(오라클이 그렇지 않다면)이 있을것에 몇몇 확신을 준다.

Web 기술들에 대한 고려 : 나는 몇몇의 Web 기술들이 주요한 이동을 계속할것이라고 추축한다. 이러한 나의 추측들은 몇년안에 있을 것이다.

브라우저와 언어들은 더이상 JQuery를 사용하지 않는 것으로 진화할 것이다.
JavaScript는 계속 주변에 있을것이지만 나는 그것이 큰 Web 어플리케이션을 작성하는 언어로서가 아니라 컴파일 타켓으로서 대부분 사용될 것을 믿는다. Dart나 CoffeeScript, TypeScript, AtScript와 같은 언어가 대안일 것이다.
Web Component가 대부분의 프레임워크를 꽤 많이 대체하리라고 나는 믿는다.

HTML5가 유행을 이끈다고 이야기하기 힘든 반면, 나는 현재 JavaFX가 오랜 지원을 한다면 그것에 호의를 보인다.

Rolling Replacement of a Java Swing Application

If you're coming from a larger Java Swing application you might want to gradually replace the existing application.

Java Swing 어플리케이션의 완만한 대체
만일 여러분이 커다란 Java Swing 어플리케이션을 다루었다면, 여러분은 아마도 현재의 어플리케이션을 서서히 바꾸고 싶어 할 것이다.

JavaFX

There is the possibility to embed Swing content in JavaFX applications so a rolling replacement seems possible. I, however, wouldn't underestimate the problems with a hybrid approach. An article by Dirk Lemmermann sums up the reasons why you shouldn't mix Swing and JavaFX. I agree with his conclusion that you're probably better off with migrating everything to JavaFX.

Swing 컨텐츠를 JavaFX 어플리케이션에 삽입할 가능성이 있다면 완만한 대체가 가능하다. 하지만 나는 혼합접근에 대한 문제를 과소평가하지 않는다. Dirk Lemmermann의 글은 여러분이 Swing과 JavaFX를 섞으면 않되는 이유를 모아놓았다. 여러분이 아마도 모든것을 JavaFX로 마이그레이션하는 것이 낮다는 그의 결론에 나는 동의한다.

HTML5

I don't see a good rolling replacement option for HTML5.

HTML5에 대한 좋은 완만한 대체는 보이질 않는다.

Deployment

배포

JavaFX

The promise of Java is "write once, run anywhere". But we've all had problems with deployment of Java programs because the user didn't have the expected Java runtime version.

Java의 약속은 "한번작성, 어디서든 실행"이다. 하지만 우리는 Java프로그램을 배포하는데 모든 문제를 가지고 있다. 왜냐하면 사용자가 기대되는 Java 런타임버전을 가지고 있지 않기 때문이다.

JavaFX has come to solve this problem through a new deployment option called Self-Contained Application Packaging: This bundles the native Java runtime together with your application code so you can always be sure about the Java version. It's even possible to do an installation without admin rights.

JavaFX는 Self-Contained Application Packaging이라는 새로운 배포 옵션을 통해 이문제를 해결했다. 이 번들은 당신의 어플리케이션 코드와 함께 네이티브 Java 런타임이 함께 묶여있어서 여러분은 항상 Java 버전에 대해서 확인 할 수 있다. 그것은 Admin 권한 없이도 설치 가능하다.

Of course, there are some caveats like the bigger download-size and that you have to build a bundle for every target platform (Windows, Linux, and Mac). The hardest part is probably to figure out a good way to deploy application updates. Currently, there is no built-in support for auto-updates but this may be included in the future. In the meantime have a look at the comments on the Feature Request for Auto-Update which includes a discussion about some alternate mechanisms.

물론, 큰 사이즈의 다운로드 크기와 같은 몇몇의 규칙과 여러분이 모든 대상 플랫폼(Windows, Linux, and Mac)에 대한 번들을 빌드해야만 하는 규칙이 있다. 가장 힘든 부분은 아마도 배포 어플리케이션 업데이트에 대한 좋은 방법을 해결하는 것이다. 현재, 자동 업데이트에 대한 빌트-인 된 지원이 없지만 앞으로는 포함될 것이다. 그동안 몇몇의 대안적인 매커니즘에 대한 논의가 포함된 'Feature Request for Auto-Update'에서의 언급을 찾아보라.

HTML5

Deploying web applications only requires a web server that users can access with their browsers. This also makes it very easy to distribute updates.

Web 어플리케이션을 배포하는것은 사용자가 그들의 브라우저로 액세스 할 수 있는 Web 서버만 필요로 한다. 이것은 또한 업데이트를 배포해기 매우 쉽다.

Result

HTML5 is the winnner in terms of deployment even though JavaFX provides a better solution than before with its native packaging.

결과
JavaFX가 이전의 네이티브 패키징 보다 낳은 솔루션을 제공함에도 HTML5가 배포에 있어서는 승자이다.

Conclusions

결론

Here is a summary of the comparison between JavaFX and HTML5:

아래에 JavaFX와 HTML5간의 비교 요약이 있다.

Criteria	Result
Richness and Aesthetics of UI UI의 풍부함과 미학	Difficult to compare. But for larger business application it is faster and easier to get nice results with JavaFX. 비교하기 어렵다. 하지만 큰 비즈니스 어플리케이션에서 JavaFX로 괜찮은 결과를 얻기가 빠르고 쉽다.
Options for Mobile and Tablet 모바일과 타블렛을 위한 옵션	Clear win for HTML5. 명확한 HTML5의 승리.
Learning Curve 학습곡선	Heavily depends on your background. Obviousely a clear win for JavaFX if you're coming from a Java or Java-like language. 아주크게 여러분의 배경지식에 의존한다. 만일 여러분이 Java 혹은 Java와 비슷한 언어에서 왔다면 JavaFX의 명백한 승리이다.
Long-term Support 장기지원	Because of fast changing trends in HTML5 I consider this a tight win for JavaFX. HTML5의 빠른 변화 트랜드 때문으로 나는 이것에서는 JavaFX에 팽팽한 승리를 고려한다.
Rolling Replacement of a Java Swing Application Swing 어플리케이션의 완만한 대체	A tie because I wouldn't rely on combining Swing and JavaFX. 나는 Swing과 JavaFX를 합치지 않기 때문에 동률이다.
Deployment 배포	A win for HTML5. HTML5의 승리

My Recommendations

나의 추천들

All criteria are relevant but I think there are two that might be relevant for most applications: Learning Curve and Options for Mobile and Tablet.

모든 기준은 대부분의 어플리케이션과 관련되어 있을지 모를 두가지에 있다고 나는 생각한다 : 학습곡선와 모바일과 타블렛에 대한 옵션들

The Leraning Curve depends on your team: How high is the team's motivation to learn web technologies? Do you have any web developers with experience in architecting complex web applications?

학습곡선은 여러분의 팀에 달려있다: Web 기술들에 대해 얼마나 많이 동기부여되어 있느냐? 여러분이 복잡한 Web 어플리케이션 설계 경험있는 어떤 개발자들을 가지고 있느냐? 이다.

If the project is large and your team has limited experience in web technologies I'd consider HTML5 as quite risky. JavaFX might be the safer choice.

만일 큰 규모의 프로젝트이고 여러분의 팀이 Web 기술들에 제한된 경험을 가지고 있다면 HTML5는 꽤 위험부담이 있다. JavaFX가 안전한 선택일 것이다.

But what if you need to support mobile devices?

하지만 여러분이 모바일 디바이스들에 지원이 필요하다면?

You could create a separate web application just for mobile. I know it would be nice to have one application that works everywhere, but this is even hard to do if you were only using HTML5. The approach of taking a fairly complex desktop UI and shrinking it down to a mobile screen usually fails. Eventually, developers come to the conclusion that they must rethink the user experience on mobile from the ground up. (That's why the mobile-first approach has gained popularity.)

여러분은 단지 모바일을 위한 개별적인 Web 어플리케이션을 만들 수 있을 것이다. 나는 그것이 어디서든 작동하는 좋은 하나의 어플리케이션이라는 것을 알지만, 여러분이 HTML5만을 사용한다면 이것조차 힘든일이 될 것이다. 꽤 복잡한 데스크탑 UI를 가지는 접근과 그것을 모바일 화면으로 축소하는 것은 대개 실패한다. 결국, 개발자들이 모바일에서의 사용자 경험을 바딱부터 다시 생각해야 한다고 결론 짓는다.

I really love Dart and the Web!

나는 정말로 Dart와 Web을 사랑한다.

This article might look like it favors JavaFX in a lot of places, but it doesn't. Most of the time HTML5 gets a lot of attention and I tried to focus a bit more on JavaFX as a reasonable alternative.

이글은 많은 곳에서 JavaFX를 선호하는 것 처럼 보일 것이다, 하지만 그것은 그렇지 않다. 주로 HTML5를 많이 다루고 있고 나는 합리적인 대안으로서 좀 더 포커스를 두려고 노력했다.

Still I must say that I just love to write programs for the web that run on many different platforms without the need to install anything. And I'm really excited about the beautiful Dart language!

나는 인스톨 없이 많은 다른 프랫폼에서 돌아가는 Web 프로그램을 작성하는 것을 좋아한다는 것을 이야기 해야한다. 그리고 나는 아름다운 Dart 언어에 대해 정말로 흥분된다!

If you decide to go with HTML5 I recommend you try Dart and Polymer.dart for Web Components. If, after a prototype, you still decide to go with JavaScript, at least use some JavaScript MVC framework (like angular.js) to give you some structure.

만일 여러분이 HTML5로 가기로 결정했다면 나는 여러분이 Web Components로된 Dart와 Polymer.dart를 시도하기를 추천한다. 프로토타입 이후에, 만일 여러분이 JavaScript로 가기로 결정하였다면, 적어도 몇몇의 JavaScript MVC Framework(angular.js와 같은) 구조를 사용용해라.

I'm aware that the criteria we looked at are only a part of what might be relevant to your specific case. I'd be glad to hear your opinion on this article and what you think is missing from the discussion.

나는 우리가 살펴본 기준이 여러분의 특정한 케이스에 관련된 것의 단지 일부인 것을 알고있다. 나는 기꺼이 이글에서 여러분이 빠져있다고 생각하는 논의에 대한 의견을 들을 것이다.

Images: JavaFX Island by Planet JFX, HTML5 Guy by Pete LePage

오역이나 누락된 사항이 있으면 아래의 메일로 연락주세요.

역자 신구인(chaos930@gmail.com)

이 블로그 검색

I'm dever