GWT 대신 jQuery를 사용해야하는 이유는 무엇입니까?

GWT 대신 jQuery를 사용해야하는 이유는 무엇입니까?

---

새 프로젝트를 위해 jQuery와 GWT 중에서 결정해야합니다.

한동안 JavaScript로 프로그래밍하지 않았고 지난 며칠 동안 GWT를 조사했습니다. 매우 멋져 보이지만 다른 브라우저와 모두에 대해 모든 다른 JS를 생성합니다.

• 자바로 개발하는 것은 jQuery를 사용하는 것보다 더 많은 시간이 걸립니다 (적어도이 프로젝트에서는)
• 문서가 좋지 않습니다 (예를 들어 페이지를 디자인 할 때 어떤 요소를 사용해야하는지 어떻게 알 수 있습니까?-이에 대한 문서가 충분하지 않습니다)

저는 대부분의 프로젝트에 jQuery를 사용해 왔으며 꽤 좋습니다.

저는 클라이언트에게 jQuery가이 프로젝트에 더 적합하다는 것을 확신시키고 싶습니다.이를 지원하려면 더 많은 논쟁이 필요합니다.

---

나는 JQuery와 함께 갈 것입니다.

한 번은 GWT 프로젝트를 유지하여 결국 두 번 다시 작성해야했습니다. 첫 번째는 리팩터링 된 GWT 앱이고 두 번째는 JQuery입니다.

나는 오랫동안 Javascript를 심각하게 다루지 않았습니다. 마지막은 2002 년경이었습니다. 저는 Java 개발자이기 때문에 GWT에 대한 첫인상이 굉장했습니다. 그러나 그것은 단지 인상이었습니다.

GWT에서 발견 한 문제 :

1. 클라이언트 / 서버 구조를 따라야합니다. 결국 내가 원하는 것은 AJAX와 그 좋은 위젯입니다. GWT의 위젯 자체는 그다지 좋아 보이지 않습니다. 심미적으로 저는 Adobe Flex를 선호합니다! 그러나 비교를 더 가깝게 유지하기 위해 JQuery의 UI는 GWT보다 좋아 보입니다. 또한 JQuery의 멋진 테마 롤러 지원이 있습니다.

2. 나는 DWR을 시도했다. 훌륭합니다. GWT보다 DWR을 사용하여 Java 코드에서 AJAX를 활성화하는 것이 훨씬 쉽습니다.

3. GWT를 사용한다면 결국 자바 스크립트를 배워야합니다. SpringSource의 Arjen은 XML과 SOAP (정확한 인용구는 아니지만)에 대해 "어떻게 WebServices를 개발할 수 있고 XML을 알지 못합니까? SOAP는 XML입니다. 피할 수 없습니다"라고 말했습니다. GWT도 마찬가지입니다. 결국 여전히 Javascript입니다.

4. 현실적으로 Javascript는 Java에 비해 배우기가 어렵지 않습니다. 더 많은 사람들이 자바보다 자바 스크립트를 알고 있습니다. 웹 디자이너조차도 그것을 알고 있습니다. 당신은 프로그래머이고 자바 스크립트가 두렵습니까?

5. 다시 작성한 프로젝트로 돌아갑니다. GWT 애플리케이션을 다시 작성했을 때 다시 작성하는 데 거의 두 달이 걸렸습니다. JQuery를 사용하면 2 주가 걸렸고 JavaScript로 인해 녹슬 었습니다.

6. JQuery를 사용하면 실제로 하드 코드 JavaScript를 작성하지 않습니다. 이것이 처음에 JQuery를 사용하는 이유입니다. GWT로 코드를 유지하는 것은 끔찍합니다. 코드에서 최근에 변경 한 내용을보고 싶을 것입니다 ... 컴파일 ... GWT를 기다립니다 ... 5 분 ... 헹구고 ... 반복하고 오류가 발생하지 않기를 바랍니다. 그렇다면 다시 컴파일하고 5 분 동안 기다립니다. 헹구고 반복하십시오. JQuery를 사용하여 줄을 변경하고 브라우저를 새로 고칩니다. 끝난.

나는 내가 여기서 객관적이지 않다는 것을 알고 있지만, 나는 단지 내 경험을 공유하고있다. :) 도덕은 자바 스크립트를 두려워하지 않는다는 것이다. Google은 어쨌든 자바 스크립트를 사용합니다

---

JavaScript를 이해하지 못하지만 Java에 더 익숙한 사람들이있는 팀을 위해 GWT를 사용하는 것이 좋습니다. GWT를 사용하면 호환성 테스트에서 몇 주가 아니더라도 며칠을 절약 할 수 있으며 언어를 처음 접하는 사람들이 부딪히는 일반적인 JavaScript 함정 을 피할 수 있습니다. GWT는 또한 CSS 스프라이트 , 임베디드 데이터 등에 대한 훌륭한 패키징 기능을 가지고 있습니다 .

그러나 JavaScript를 알고 이해한다면 라이브러리가 무엇이든 상관없이 JavaScript를 사용할 것입니다. GWT에서 생성 된 코드를 너무 면밀히 검사 할 기회는 없었지만 Google I / O에서 몇 가지 예제를 보았고 모든 것이 멋지고 반짝이는 것처럼 보였지만 기존 방식으로보다 우아한 JavaScript 코드를 만들 수 있습니다. 방법.

---

그룹이 Java에 가장 익숙하고 상당한 양의 클라이언트 측 기능을 수행 할 계획이라면 최소한 GWT를 평가해야합니다. 유형 안전성, Eclipse 디버깅 및 서버 측 / 클라이언트 측 간의 공유 코드는 Java 개발 팀에게 편안함을 느낄 것입니다.

그러나 팀이 jQuery 또는 다른 JavaScript 라이브러리를 사용한 JavaScript 프로그래밍에 익숙하다면 순수한 JavaScript 기술을 고수하는 것이 더 쉬울 수 있습니다. GWT는 대부분의 JavaScript 개발자에게 익숙하지 않은 페이지의 큰 섹션을 차지하는 방법을 가지고 있습니다. 페이지를 인수한다는 것은 일반적인 GWT 코드가 페이지의 기존 요소에 기능을 추가하는 대신 자체 DOM 요소를 만드는 것을 좋아한다는 것을 의미합니다. 이것이 페이지가 처음로드 될 때 많은 GWT 앱에 '로드 중 ...'화면이있는 이유입니다. 이것은 필수는 아니지만 가장 일반적인 GWT 개발 스타일입니다.

생성 된 코드가 GWT에서 나온다는 사실은 대부분의 GWT 개발자에게 덜 관련성이 있습니다. GWT를 사용하면 Java를 일반 java * .class 파일과 동일한 것으로 컴파일 할 수 있지만 웹 브라우저가 해석하는 방법을 이해하는 JavaScript 구문으로되어 있습니다. GWT는 템플릿 기반 코드 생성기보다 컴파일러처럼 작동합니다. 생성 된 코드를 검사해야하는 경우가 있지만 대부분의 경우 디버깅은 Java 디버거를 통해 Java로 이루어집니다.

고려해야 할 또 다른 사항은 선택한 클라이언트 측 기술에 관계없이 개발 팀이 일반적으로 HTML, JavaScript, CSS 및 브라우저 프로그래밍에 익숙해야한다는 것입니다. GWT를 사용하면 익숙한 Java 환경에서 클라이언트 측 코드를 작성할 수 있지만 브라우저 내에서 작업하고 있다는 사실을 숨기지 않습니다.

---

우선 GWT와 jQuery를 비교하는 것은 의미가 없습니다. jQuery는 크로스 브라우저에서 DOM을 훨씬 쉽게 사용할 수 있도록 빌드되었지만 GWT는 대규모 웹 애플리케이션을 만들기 위해 빌드되었습니다.

따라서 캘린더, 슬라이더 등과 같은 독립적 인 위젯이있는 정적 측면이 많으면 jQuery로 충분합니다. 대규모 팀과 함께 단일 페이지 앱을 빌드하려는 경우 GWT가 더 나은 방법입니다. GWT는 특히 MVP 패턴 빌드, UI-Binder 템플릿 시스템, i18n 지원 등의 설계 아키텍처를 잘 갖추고 있습니다.

따라서 대규모 GWT 앱에서 1 년 이상 작업하는 JavaScript 개발자로서 jquery로만 단일 페이지 앱을 빌드하지 않는 것이 좋습니다. JavaScript를 사용하고 싶다면 백본, 척추, 녹아웃 또는 도장을 살펴보십시오.

Btw, GWT 아키텍처가 훌륭하므로 JAVA 오버 헤드가 많이 발생합니다. 따라서 프로젝트가 커지면 CSS 및 i18n 속성을 컴파일하는 시간이 성 가실 것입니다.

---

"강좌 용 말"

프로젝트에 가장 적합한 것을 선택하십시오. 고려해야 할 사항

• 촉박 한 시간 척도 및 다른 것보다 더 친숙 함
• 다른 개발자가 선택한 도구를 사용할 수있는 속도 및 유지 관리 용이성. 다른 것보다 하나의 보급은 여기에도 영향을 미칠 수 있습니다.
• 프로젝트에서 이미 사용할 수있는 코드 (예 : 플러그인, 유틸리티 함수 등)가 있습니다.

프로젝트가 무엇인지, 귀하의 경험이 무엇인지, 클라이언트가 다른 기술 / 프레임 워크를 사용하는 방법에 대한 세부 사항을 알지 못하면 여기에서 결정적인 답을 찾을 수 없습니다.

내가 여기서 시작했듯이 서로에 대한 설득력있는 주장 목록을 작성한 다음 프로젝트에 관련된 다른 사람들과 논의하여 결론을 내립니다.

---

대답은 쉽지 않습니다. 대답은 "상황에 따라 다름"입니다.

GWT :

• 자바를 알고 좋아한다면
• 서버 코드가 Java로도 작성된 경우 Java로 클라이언트 코드를 작성하면 클라이언트와 서버에서 동일한 코드를 사용할 수 있습니다.
• 강력한 형식의 언어에서 제공하는 것을 좋아한다면 컴파일 타임 형식 검사, 자동화 된 리팩토링, 자동화 된 코드 생성 (Eclipse에서는 Ctrl + 1), 코드 완성 (Ctrl + Space)
• 컴포넌트 지향 프로그래밍을 좋아한다면 (예 : MenuBar가 메뉴를 생성 함)
• GWT의 복잡성 (jQuery와 비교)이 문제가되지 않는 경우
• 큰 생성 코드가 문제가되지 않는다면

jQuery :

• 자바 스크립트를 알고 좋아한다면
• you don't need to use the same code on client and server (eg. client - JS, server - Java or PHP)
• if you don't need compile-time type checking, automated refactoring, etc
• if you don't need component-oriented programming (to create a complex component in jQuery you need to create a series of divs, and call $("those divs").makeXXXXControl())
• if you like simplicity (jQuery is simpler than GWT)
• if you need very small code (eg to make website loading faster)

Personally I would recommend GWT for most projects, but jQuery also has pros and some people may prefer jQuery.

---

I agree with Russ Cam that it depends on what your team is familiar with. When I am doing work for my personal business apps, I much prefer GWT. I find javascript, even with jquery, to have annoying object oriented syntax. If you have an app with 10,000 lines of UI code, jquery strikes me as something that would lead to a mess of hard to maintain code with poor reuse.

Does anyone know of a large scale project done in jquery?

I think if you are trying to squeeze every last byte out of the resulting filesize, don't use any library and write the javascript from scratch (ie: google homepage fade effect).

Something to think about regarding javascript/jquery versus gwt. If you use common object oriented principles and design patterns, you will likely get better performing code with gwt. Why?

Let's take the example of polymorphism. If you write an app that uses heavy polymorphism in javascript, you will get the benefit of maintanability and code reuse this provides. However, your code will also get the performance hit of using polymorphism.

Now, if you used gwt, you will also get the benefit of maintanability and code reuse this provides, BUT the gwt compiler will optimize away the polymorphism into concrete class usage, hence increasing performance.

---

I think GWT is too much abstraction. Javascript is in fact a powerful language. You can write object oriented code and use namespaces. With a library like jQuery you won't have to worry about browser compatibility issues for most of what you do. With all the great browser developer tools available (like Firebug) in all major browsers now a days it is very easy to work with javascript. When a javascript error occurs I can easily pinpoint where it happened in my code. I can watch variables and know all that is going on in detail because I am working against code I wrote (unlike GWT).

---

The main problems I see with GWT vs. a native Javascript solution (jQuery or others) are:

• There is an additional process that separates you from your final product. You develop your app in Java and you debug the Java code, yet you release a machine translated version of this code. For a decently sized app I can't imagine that you won't need to debug the actual code running on the browser at times, and this is going to be a headache, since it isn't your code.

• Since you write your code in Java you are limited to use Java libraries. If you find some JS library that you like it would be awfully difficult to add it to your GWT project, you may need to write a Java wrapper for it. If you are developing native JS you can just add it to your project.

• JS is an awesome language in its own right, with a solid object model that is different than Java's. I have developed a few apps in native JS for HP webOS and was surprised to find that many of the preconceptions I had about the language were not true. You can write clean, efficient and maintainable code in JS as much as you can in Java, and if you take the time to understand the JS object model you won't even need to use a support library to mimic a more typical class/object model like those of Java and C++ on top of JS. Javascript's prototypes are pretty cool.

• If you may ever consider releasing your app on mobile platforms, then a native JS app can easily be wrapped inside phonegap and have access to several mobile platforms, without additional effort. There is a GWT wrapper for phonegap as well, but going back to my first item, if you have the choice to work with the real thing then why choose a solution that requires translation/emulation?

Good luck.

---

All the great tips and no one spoke about JSNI! A feature in GWT that allows you to use javascript if you wish.

https://developers.google.com/web-toolkit/doc/latest/DevGuideCodingBasicsJSNI

---

jQuery = low-level understanding

Aside from the normal one javascript and the other is java explanation, Jquery has a closer one-to-one mapping with javascript while GWT is more abstracted away. So if you prefer to have a deeper understanding of what's happening with your code at the low-level (javascript) then jquery is the right way.

GWT = abstraction understanding = functional guarantee

GWT offers the advantage of compiler generated code so it may offer more of guarantee that your website will function normally. However like any large scale API you need to take the time to understand what this class does and what that class does and whether or not it is compatible with this API or nor.

low-level understanding may be more useful

Personally I get much more satisfaction from coding the low-level myself. I have built some web applications at work from pure javascript that functioned flawlessly. Once wrote javascript code that took data from a database and generated a complete microsoft word research report. The complexity of this project demanded a lower-level grasp of javascript. I'm not sure this could have been done easily with a java based solution.

GWT reassures managers but costly

But then again java and asp.net tend be preferred by larger companies b/c there is greater technical support (i.e. Oracle and Microsoft) and uptight on-the-edge managers tend to get better sleep at night when they know they can solve problem A by simply paying x amount of dollars for support. So after adopting the system they soon start realizing that technical support costs too much and it's cheaper to pay more for better developers. Hence a java or .net career will usually put food on the table.

Maintainability

Also API's like GWT are easier to maintain. I could only imagine the horror that someone would go through if they had to debug my javascript code. But that was before I became a better and cleaner programmer and since I knew every aspect of the code there is nothing to debug b/c there was never a problem with it.

Low-level coding gives you almost a 100% understanding of what is happening, however with API's you spend time playing bug detective on google and posting questions on sites like StackOverflow. But managers don't understand this b/c most aren't programmers.

---

GWT is a compiler (Java to JavaScript) and jQuery is a framework. You don't have to choose one over the other. You can use one of them, both or neither.

For instance you can code in Java if you want to or have existing source code and then use jQuery for other stuff. There are available wrappers, but GWT can call JavaScript (and vice versa) see http://svenbuschbeck.net/wordpress/2012/06/how-to-use-jquery-in-gwt/

---

my personal opinion would be for jQuery but thats because I never use Java and really like using the jQuery plugins.

---

Active user group and recent gaining popularity clearly indicates jQuery is the winner.

참고URL : https://stackoverflow.com/questions/1205278/why-should-i-use-jquery-instead-of-gwt