Grails (현재)는 그만한 가치가 있습니까?

Grails (현재)는 그만한 가치가 있습니까?

---

나는 이것이 중복 이라는 것을 알고 있지만, 그 질문이 Eclipse에서 IDE 지원과 마찬가지로 1 년 이상 전에 질문 된 이후로 Grails 세계는 상당히 발전했습니다. 그러니 맹목적으로 닫지 마십시오.

나는 대답이 '예'라고 생각했고 Grails 1.2.0 으로 새로운 프로젝트를 시작 했으며 STS Eclipse Integration 의 Groovy / Grails 비트를 사용했습니다 .

나는 그 질문에 대한 답이 확실히 섞인 Grails 진화의 1 년 후에 재검토 할 가치가 있다고 생각한다.

따라서 숙련 된 Java 웹 개발자로서 다음과 같은 질문이 있으며 내 가정 에 도전 해 주셔서 감사합니다 .

• Grails는 이제 Ruby에 비해 가치가 있습니까?
• 버그가있는 시작을 극복 했습니까?
• 정말 빠른 개발 이점을 제공합니까? (저는 목록 및 페이지 지향이 아닌 맞춤형 앱을 만들기 위해 광범위한 기본 구성을 지나서 어려움을 겪고 있음을 인정합니다)
• 실제 프로덕션 앱에서 작동합니까? (무거워요)
• Eclipse 플러그인이 이전보다 낫고 목적에 적합합니까? (아직은 생각하지 않습니다)

감사

편집 : 나는 나 가면서 배우고 있으며 프레임 워크 기능 자체보다는 프레임 워크와 함께 생활하는 것에 대해 몇 가지 중요한 불만이 있습니다. 나는 그것들이 고려되어야한다고 생각하고 내 경험과 의견을 기반으로하고 성배를 결정하려는 사람을 도울 수 있기 때문에 추가하는 것입니다. 또한 프레임 워크에 대한 경험이 부족하다는 것을 보여줄 수 있으므로이 중 어느 것도 외부 비판을 의미하지 않습니다. 저는 숙련 된 개발자이며 이것이 제가 찾은 것입니다.

디버깅은 정말 어렵습니다 . 사실 그것은 거의 불가능합니다. 특히 프레임 워크의 초보자로서 믿을 수있는 디버거 친구가 가장 필요할 때입니다. 스택 어딘가에서 조용한 오류를 일으키는 도메인 필드를 참조하는 것과 관련하여 코드의 일부에서 구문 오류의 문제를 추적하는 데 필요한 것보다 더 많은 시간을 보냈습니다.

로깅은 솔직히 끔찍 합니다. 두 가지 모드, "유용하지 않음"과 "과도한 양의 쓸모없는 것"이 ​​있습니다. 내 디버그 로그는 단일 페이지 요청 후 128Mb였으며 내 오류에 대한 내용이 없습니다. 로깅의 전체 문제는 제 생각에 프레임 워크에서 재검토가 필요합니다.

STS Eclipse IDE는 한계가 있습니다 . 구문 강조 이외에는 많이 사용되지 않습니다. 코드를 디버깅 할 수 없으므로 훌륭한 편집기입니다. 코드 힌트는 고르지 않으며 내가 볼 수있는 한 GSP 지원이 전혀 없습니다. 또한 내 데스크탑에있는 가장 느린 Eclipse 플러그인입니다. 시작하는 데 약 2 분 정도 걸립니다. 놀랍게도 느립니다. 텍스트 편집기 (모든 온라인 튜토리얼 비디오에서도 마찬가지 임)와 일부 사용자 지정 구문 강조로 돌아갔습니다.

성능에 대해 심각한 우려가 있습니다. 말하기에는 너무 이르지만 이미 최대 절전 모드로 인해 데이터베이스를 조정하고 있습니다. 아마도 그것은 예상 할 수 있지만, 성능 쿼리를 생성하기 위해 규칙에 대해 도메인 모델을 단순하게 유지해야합니다.

마지막으로, 논리적 도메인 모델과 물리적 데이터베이스 모델이 동일해야한다는 규칙은 현명한 기본값이 아니며 현실 세계에서는 불가능할 것입니다. 나는 당신이 둘을 분리 할 수 ​​있다는 것을 알고 있지만, 그것은 관습이 확장된다면 피할 수있을 정도의 복잡성을 만들어 낸다. 구성에 대한 문서가 부적절 하고 실제로 작동하도록하려면해야 할 일이 있습니다 .

---

저는 지금까지 4 개월 이상 Grails를 사용해 왔으며 Grails와 그 유용성에 대한 개인적인 느낌을 드리려고 노력할 것입니다.

Grails는 이제 Ruby 또는 다른 롤에 비해 가치가 있습니까?

물론 대답은 '예'또는 '아니오'가 아니지만 상황에 따라 다릅니다 . 요구 사항 (Java World에 있어야합니까?), 선호도 (도메인 지향 개발을 선호합니까, Groovy를 선호합니까 ...)에 따라 다릅니다. 그러나 Grails는 Rails의 심각한 대안이라고 대답 할 수 있습니다. Rails 애플리케이션이 무엇이든 Grails로도 할 수 있다고 생각합니다. 그러나 프로젝트의 성격에 따라 다소 시간이 걸릴 수 있습니다. 다시 말하지만, Rails에는 익숙하지만 Grails에는 익숙하지 않다면 Rails가 더 안전한 옵션입니다.

버그가있는 시작을 극복 했습니까?

네 . (이 웹 사이트 나 다른 웹 사이트에서) 제 초기 메시지를 살펴보면 Grails 버그에 대해 많은 불평을했습니다. 그러나 Grails는 가장자리에서 약간 거칠고 (예를 들어 도메인 상속을 너무 많이 사용하지 않음) 프레임 워크에 익숙해지면 너무 나쁜 놀라움을 경험하지 않는다는 점을 기억해야합니다. Grails가 버그가 아니라는 말은 아닙니다. 확실히 Rails 이상입니다. 또한 버그보다 유용 합니다. 이에 대한 조언 : 가능한 한 적은 플러그인을 사용하십시오 . 그들 중 많은 것이 버그가 있고 일부는 서로 호환되지 않기 때문입니다. 따라서 grails 플러그인이 최신 상태이고 방해가되지 않으며 테스트를 거친다는 확신이없는 한 grails 플러그인을 포함하지 마십시오.

정말 빠른 개발 이점을 제공합니까?

네 . DB 디자인을 거의 다룰 필요가 없습니다. 구성보다 규칙 덕분에 처음부터 구성이 거의 완료되었습니다. 응용 프로그램을 쉽게 유지 관리 할 수 ​​있습니다. 내가 본 유일한 단점은 다른 기술 (예 : Rails 또는 ASP)만큼 풍부하지 않은 프런트 엔드 개발입니다.

실제 프로덕션 앱에서 작동합니까?

나는 아직도 내 웹 사이트를 라이브로하지 않았기 때문에 말할 수 없지만 sky.com 이 Grails를 사용하고 있고 사이트가 하루에 약 700 만 페이지 뷰를 끌어 들이고 있기 때문에 꽤 확신 합니다 . 다시 한 번 성능은 애플리케이션 아키텍처와 디자인 결정에 크게 좌우됩니다.

Eclipse 플러그인이 이전보다 낫고 목적에 적합합니까?

몰라요. IntelliJ를 사용하고 있지만 Grails 영역에서보고있는 불평 메시지에 따르면 1 년 전보다 낫지 않은 것 같습니다.

도움이되기를 바랍니다.

---

최근에 Rails 프로젝트를 시작했고 Grails로 몇 가지 일을하고있었습니다.

나의 중요한 것은 레일 (싫어) dev에 완전히 불투명 한 물건이 많이있을 것입니다, 이것은 더 추가 시작할 때 증가하는 경향이 플러그인을 / 발전기 / libs와 / 등 때문에 그들을 결합하기 위해 무언가를 패치해야합니다. rails + plugins 는 플러그인 + 버전 의 잘못된 조합을 사용하면 깨지기 시작하는 거대한 DSL 해킹이라는 느낌을받습니다 .

Grails를 사용 하면 생태계가 훨씬 작지만 모든 것이 비교적 일관된 경향이 있습니다. DSL 접근 방식은 그다지 사용되지 않으며, 기존이지만 지루한 설계 (DSL 대신 클래스, 인터페이스 등을 사용하는 것을 의미)를 사용하면 배관이 어떻게 작동하는지 훨씬 쉽게 이해할 수 있습니다.

일대일 비교를 수행하는 방법은 다음과 같습니다.

• 언어 구현 : Ruby를 잘 모르지만 Groovy보다 Ruby를 선호합니다. Groovy는 일부 기능이 구문 위에 결합 된 좋은 의도-나쁜 구현 언어처럼 느껴집니다. 나는 단지 약간의 해킹을 허용하기 위해 존재하는 것처럼 보이는 몇몇 특별한 클래스를 언급하고있다.
• 프레임 워크 기능 : Rails는 이보다 훨씬 앞서 있습니다. Rails의 대부분의 측면 (예 : 레이아웃, 템플릿, css / js 패커, 유효성 검사, 프레임 워크 테스트 등)을 여러 가지 방법으로 구성 할 수 있습니다. Grails는 대부분의 사용 사례에 충분히 유연하지만 이에 뒤처지고 있습니다.
• 플러그인 : Rails에는 축복이나 악몽으로 보일 수있는 수많은 플러그인이 있습니다. 일부 플러그인은 유지되지 않고 다른 플러그인은 일부 기능이나 플러그인과 잘 작동하지 않으며 많은 포크가 있습니다. 저는 기본적이고 가장 많이 사용되는 플러그인 (authlogic, haml 등)을 고수하는 방법을 배우고 있습니다. Grails에는 기본 (권한 부여 / 인증, ORM 등)에 대한 우수한 플러그인과 소규모 작업을위한 다른 플러그인이 있습니다.
• 테스팅 : Rails는 테스팅을 위한 많은 방법을 가지고 있지만 이것이 반드시 좋은 것은 아닙니다. 일부 테스트 프레임 워크는 일부 플러그인과 잘 작동하지 않습니다. Grails는 테스트 플러그인이 적지 만 일부 주요 플러그인과 더 잘 통합되는 경향이 있습니다 (통합 할 플러그인이 많지 않기 때문).
• 데이터베이스 : Grails 가 훨씬 승리 합니다 .
  • DB를 해킹하는 대신 도메인 클래스를 모델링하는 것을 선호합니다.
  • Hibernate (내부에서 사용됨)는 Rails에서 몇 년 떨어져 있습니다. Rails 용 데이터 매퍼 (ActiveRecord보다 Hibernate와 본질적으로 더 유사 함)가 있지만 충분히 성숙하지 않은 것 같습니다. Grails에는 플러그인을 통한 마이그레이션도 있습니다.
  • Hibernate (JBoss 캐시, EhCache 등)에 대한 훌륭한 캐시 구현을 통해 지붕을 통해 성능을 높일 수 있습니다.
• 라이브러리 : Ruby에는 NoSQL 또는 Cloud 서비스와 같은 새로운 항목을위한 많은 라이브러리가있는 반면 Java에는 Excel 처리와 같은 오래된 항목을위한 무수히 많은 라이브러리가 있습니다. Java 라이브러리가 일반적으로 Ruby보다 훨씬 빠르다는 것을 잊지 마십시오.
• 최첨단 : Rails는 더 과장되어 더 많은 리소스를 보유하고 있습니다. 즉, MongoDB 또는 Riak을 Rails와 통합하려는 경우 누군가가 이미 만든 좋은 변경 사항이 있습니다. Grails는 그다지 인기가 없기 때문에 뒤처져 있습니다. 따라서 커뮤니티는 NoSQL 등과 같은 모든 최첨단 도구를 사용하는 대신 일상적인 문제를 해결하는 데 집중하는 경향이 있습니다.

예를 들면 다음과 같습니다.

• 대부분의 grails 플러그인은 모델 및 / 또는 서비스의 형태로 코드를 생성합니다. 나머지는 일반적으로 도서관에서 처리합니다. 모델 / 서비스 코드를 검사하고 기능을 확인하고 변경할 수 있습니다.
• 대부분의 Rails 플러그인은 일반적으로 Rails API와 연결됩니다. 즉, 일부 함수를 호출하거나 일부 모듈을 포함한 다음 플러그인 자체 DSL을 사용합니다. 이것은 작동 할 때 훌륭하게 작동 하지만, 깨지면 끔찍하고 결국 일부 항목을 패치하거나 다른 플러그인 또는 플러그인 버전을 설치해야합니다. 나는 더 노련한 Rails 개발자가 이것에 더 편하다고 생각하지만 나는 그렇지 않습니다.

---

결론:

• 블리딩 엣지를 원하고 가끔 패치하는 것을 신경 쓰지 말고 대규모 커뮤니티를 선호하거나 ActiveRecord 스타일 DB를 사용하는 것을 신경 쓰지 말고 Rails를 사용하십시오 . 게다가 언어로서의 Ruby는 매우 우아합니다.
• DSL 대신 클래스 인터페이스 디자인을 선호하고 모델을 통한 앱 모델링을 선호하고 절묘한 기능이 필요하지 않으며 Java 에코 시스템에 익숙하다면 Grails를 사용하십시오.

---

그만한 가치가 있습니다!

우리는 여러 프로젝트에서 Grails를 사용하고 있으며 모두 다음과 같은 이유로 큰 성공을 거두었습니다.

• 쉬움-우리가 사용한 가장 쉬운 프레임 워크 중 하나입니다.

• 레거시 코드 재사용-우리가해야 할 일은 레거시 코드를 가져 와서 lib 또는 src 폴더에 던지기 만하면됩니다. 우리에게 아주 좋습니다.

• 레거시 데이터베이스 구조-레거시 데이터베이스에서 데이터 시각화를 생성하려는 경우 훌륭한 도구입니다.

이제 생존력에 대해 :

• 버그 : 버전 1.1 이후로 버그가 너무 많지 않았습니다 (버전 1.0은 우리에게 너무 버그가 많았습니다).

• 도구 : Netbeans는이면에서 실제로 개선되고 있지만 Intellij IDEA와 같은 다른 도구도 가깝지 않습니다 (큰 지원!). Eclipse에 대해서도 마찬가지입니다.

• 이식성 : 우리는 프로젝트에서 단 하나의 문제에 직면 한 적이 없습니다.

---

현재 6 개의 Grails 애플리케이션이 프로덕션에 있으며 Grails는 자바 프레임 워크와 다르며 학습 시간이 약간 필요하지만 애자일 기술을 사용했기 때문에 성과를 거두었습니다. 세부:

• IntelliJ를 사용합니다. 그다지 비싸지 않으며 우리를 위해 몇 주 만에 상환되었습니다.
• 모든 동적 언어 코드의 경우 자동화 된 테스트, 지속적 통합 및 리팩토링이 필수입니다. 이미 TDD를 연습하거나 적어도 괜찮은 테스트 코드 커버리지가 있다면 추가 작업을 추가하지 않습니다.
• Hibernate는 기본적으로 Grails와 함께 제공되지만 다른 지속성 프레임 워크를 사용할 수 있습니다. 현재 사용 가능한 다른 5 가지 지속성 플러그인이 있습니다.
• 벌목은 Graeme Rochers의 마음에서 분명히 관심사가 아니었지만 꾸준히 개선되었습니다. 하지만 오류가 기록되지 않은 문제는 발생하지 않았습니다 (코드에서 예외를 올바르게 포착해야 함).
• 디버깅은 분명히 레이더에 없었습니다 (그러나 개선되지 않았습니다). 어쨌든 우리는 디버깅에 의존하지 않습니다.

이것은 모든 새로운 기술과 마찬가지로 프로토 타입, 코드 검토, 쌍 프로그래밍을 만들고 컨설팅을 사용하는 것이 좋습니다.

---

그만한 가치가 있습니다. 나는 그것을 1 년 넘게 사용하고 있고 그것을 좋아한다. 나는 이러한 유형의 rad 도구를 피하곤했지만, 그것은 내가 일하는 방식을 바꾸어 놓았습니다. 1.2 릴리스에서는 더 나은 스택 추적 정보 (특히 GSP의 경우)로 더욱 향상되었습니다.

스케일링과 관련하여 내가 가진 유일한 문제는 최대 절전 모드였으며 캐시 문제입니다. 이것은 실제로 성배 문제가 아닙니다. 내가 일반적으로 최대 절전 모드를 좋아하지 않는 사람들조차도 grails가 GORM으로 그것을 감싸는 방식은 나에게 예술 작품입니다. 기준 클로저 측면은 작업하기에 훌륭합니다.

---

나는 아직 Grails와 Rails 모두 전문가이고 Grails를 선호하는 사람을 찾지 못했습니다.

둘 다 잘 알고 있다면 Rails를 선호 할 것입니다.

Grails는 일반적으로 플랫폼 변경을 두려워하는 Java 개발자에게 어필합니다.

이 경우 JRuby가 노후화 된 레거시 jvm에 민첩한 접근 방식을 채택하는 더 나은 방법이라고 생각합니다.

---

최근에 프로젝트에 Grails를 사용하여 표준 J2EE 애플리케이션 개발과 비교 한 경험을 공유하고 싶습니다.

정말 빠른 개발 이점을 제공합니까?

확실히 그렇습니다. 비계 경로가 일찍 남겨지고 관습이 자신의 필요에 따라 재정의 되더라도 많은 다른 기술을 신경 쓸 필요가 없기 때문에 시작 기간이 매우 짧습니다. 이러한 경량화로 인해 작업 속도가 빨라질뿐만 아니라 더 정확하고 깨끗합니다.

태그를 작성하는 것은 결코 쉬운 일이 아닙니다. JSF를 사용하면 먼저 노력할만한 가치가 있는지 고민하고 Grails를 사용하면됩니다. 다른 테스트 사례와 조롱 전략이 때때로 일관성이없고 버그가 많지만 테스트 중심으로 작업하고 높은 커버리지 비율을 달성하는 것도 매우 쉽습니다.

Java에서 Groovy로 전환하는 것은 큰 기쁨입니다. 우리는 목록 및 맵 리터럴, 클로저, 빌더를 사용하여 Java에서 보일러 플레이트 "맵"구현을 버리고 간결하고 의미 있고 집중된 코드를 작성하는 것을 좋아했습니다.

개발 속도를 늦추는 것은 우리가 사용하는 IntelliJ 플러그인에도 적용되는 완벽한 IDE 지원이 아닙니다. 여러 장소에 흩어져있는 ( "검색이 끝났습니다"라는 약속을하는) 불량하고 종종 오래되고 심지어 잘못된 문서도 급속한 개발을 방해합니다. 그래서 우리는 종종 소스 코드 읽기로 돌아 가야했습니다. 이후 기본 Spring 클래스 계층 구조에 겁을 먹었습니다.

---

디버깅은 정말 어렵습니다. 나는 이것이 큰 문제라는 것을 결코 발견하지 못했습니다. 디버거를 연결하고 살펴 보거나 코드에 println / logs를 추가하여 무슨 일이 일어나고 있는지 알아낼 수 있습니다.

로깅은 솔직히 끔찍합니다. 나는 스택 추적이 일반적으로 4 페이지의 쓸모없는 정보를 제공하는 데 동의하며 가끔은 유익한 줄을 제공합니다. 그러나 그러한 멋진 프레임 워크에 대한 비용은 적습니다.

STS Eclipse IDE는 한계가 있습니다. Eclipse는 Grails에 대한 지원이 열악합니다. 가능하면 IntelliJ를 사용하십시오. 나는 빡빡하지만 회사가 허락한다면 IntelliJ에 대한 현금을 기꺼이 지불 할 것입니다.

---

저는 1.0- 베타 초반부터 Grails를 사용해 왔으며 Java 상점에서 온 경우에만 Groovy / Grails를 진지하게 받아들이는 것이 좋습니다.

Java 상점이고 Ruby Rails를 고려하고 있다면 Grails로 이동하십시오. grails가 작동하지 않으면 언제든지 Rails를 시작할 수 있습니다.

---

거의 10 개의 애플리케이션에서 Grails를 사용한 3 년 간의 경험을 공유하겠습니다. Ruby on Rails와 비교할 수 없으므로 다른 질문에 답하겠습니다.

버그가있는 시작을 극복 했습니까?

• 네, 그것은이. Grails 2.0.4 / 2.2.4에서 몇 가지 Grails 버그를 경험했습니다.

정말 빠른 개발 이점을 제공합니까?

• 배우기 쉽고, 개발하기 쉬우 며, Java 세계에 대한 좋은 지식을 가진 사람이 기본을 아는 데 일주일 이상 걸리는 것을 본 적이 없습니다. 유지 관리도 쉽습니다. 그리고 DB에 대해 많이 걱정할 필요가 없습니다.

Eclipse 플러그인이 이전보다 낫고 목적에 적합합니까?

• Choose your IDE very carefully. Eclipse helped me a lot but it crashes and causes more trouble than it should. I went for IntelliJ and in the trial month it seemed a better choice. Lately I've been using Sublime Text, a few plugins and the old command line. I only go to a IDE in special situations - to use its debugger, for example.

Does it perform for real world production apps?

• It is kind of heavy. Research a lot on your design choices BEFORE writing your models. Do lots of research about good Grails design. Most of the things I've done two years ago I can realize how to make it better now since I'm more experienced. It handles real world production apps well but depending on the mistakes you make Hibernate can really be a headache.

---

The Grails Eclipse plugin is crap. It crashes for no reason at all, and doesn't really support Groovy's flexibility. NetBeans and IntelliJ are rumoured to be much better, but I haven't tried them yet.

Does it perform? Of course it does. Even Ruby on Rails performs, as long as you throw enough servers at the problem. I have no idea how Grails compares to various Java frameworks, though.

Does it really confer rapid development benefits? Well, I'm still missing a lot of good Ruby/Rails stuff. It doesn't recognise Date and Enum request params automatically (then again, Rails also has some issues with Dates), TimeCategory should be part of the standard configuration but isn't. But there's also a lot of stuff that requires remarkably little configuration.

It's not quite where Rails is (I'm particularly looking forward to Rails 3), but it's a lot more pleasant to work with than many Java frameworks. Even so, the magic below the surface goes way deeper than in Rails. For example, the system for Constraints is really powerful, but built on top of a huge layer of impenetrable Spring stuff, and really inflexible if you want to use that same power in a slightly different way. Rails is easier to subvert, IME.

Is it worth it? Yes. Is it a better choice than something else? That depends.

---

I would suggest you try for yourself. I love the flexibility of Grails and the Development Speed. However as you can see other people's experience differs. I want to be able to develop rapid applications for my clients using the Java Platform and I have found Grails to work very well for us.

I have also found the frontend very flexible to develop. I also think you need to use common sense and choose your plugin's carefully. I stick to the plugins supported by springsource.

---

In my experience, Grails bring a few very attractive features on the table which definitely makes worth learning and using it.

• Agility - things we used to take weeks to implement in conventional J2EE projects are generally a day's work with grails plugin system. Things like ajax, jquery ui, acegi, restful implementation, scheduler system and lots of them
• Runs on JVM which alleviates need to learn some other run time system and its idiosyncracies

• Java like syntax and groovy syntax sugar. like best of both the worlds. You can immediately start with Java instead of learning syntax of new language like Ruby and then slowly you can move to groovy syntax which is robust, easy and intuitive

  For the project managers, unless there is compelling reason for "not to use" grails for some reason( resistance from higher up, to adopt new technology or something), I don't see any reason why grails can't be used or at least tried.

To answer the concern about debugging, it's not that hard. Debugging is easy if you use Netbeans IDE. That brings me to one more point to mention. After few experiments with all the IDEs we found that Netbeans is the most suited to do the job. It has better support for code completion, syntax highlighting and debugging etc. In my opinion, STS is not good enough for that.

---

Is the Eclipse plug-in better than it was and fit for purpose?

It had definitly improved a lot over the last year. In Dec I attended the Groovy&Grails Exchange in London. There was a great talk regarding the Groovy&Grails integration in Eclipse/SpringSource STS that has been recorded, see the video.

From my point of view, Eclipse gained a lot of ground. Currently IntelliJ seems to be a slight bit ahead but that might change within the next few months.

---

Regarding the eclipse plugin, is still coming its way, but you can use the eclipse version from Spring Source (SpringSource Tool Suite)

http://www.springsource.com/products/sts

It's quite decent compared to the previous plugin versions, and since Spring Source has acquired the company responsible for grails and groovy, you can expect that STS will become better quickly

---

Personally, I learnt RoR and used it for a few home projects, but then switched to Grails, mostly because it runs on the JVM and therefore I am hoping to make use of the plethora of Java performance/profiling programs, which should help identify any bottlenecks in code before they become a problem.

In general I haven't found too much difference in the quality of IDE's used by RoR vs Grails. Although, to be fair, I'm programming on Linux and haven't tried TextMate for RoR development. When I was using RoR I used Netbeans.

Right now I am programming using STS and am finding it a pleasure to use with Grails, although I still find that method detection/completion could be made to work much better.

---

I'm a full time java developer but use rails for my hobby projects. We evaluated grails for a project at work a year back. My experience with grails left me feeling a bit disappointed and this was the reason that I began to investigate rails. Having used both my impression is that even though groovy is not far behind ruby as a language, rails provides a significantly improved experience over grails. Quite simply, rails seems to solve far more real world problems, particularly when you factor in the number of good gems that are available. I'm thinking of things like, providing search, versioning, rss, non crud apps, integration with cloud services, etc. I get the impression that grails is around about the level of rails 1.x. By the end of this month rails 3 should have been released. We've actually decided to now move towards using rails at work. In the end, grails is easier to pick up for java developers, but ultimately lacks the refinement to cover a wider range of project requirements.

---

I would say no. It is too still bloated, imho, for most uses, especially if you just want to prototype something. We don't need all of that code, all those dependencies bundled with grails in order to make a web application. You don't need spring every single time you want to put out a web application. Look at what you are trying to accomplish before you add a whole world full of dependencies to your stack. I think it's important to know what your application comprises of.

I recommend looking at something like ratpack, which is much lighter, almost like sinatra for ruby.

---

I want to point out to two more considerations, memory usage and job market. Grails application takes a lot of memory especially in development mode e.g. 600 Mb for a medium sized application. When deployed in production mode, e.g. war file in Tomcat, the usage can be about 500 Mb. This is partly inherited from using Java.

As for job market and as far as I have read, there is little demand for Grails programmers in job vacancy announcements compared to e.g. Django and Ruby on Rails.

---

From my experience as of end of 2013.

Pros

• when you use very little of the plugins and confine a set of Grails no-s and never-s, it's quite a smooth developing experience

Cons

• Refreshing (F5) is always a problem. And this is the most annoying. For some reason I had to restart the server on each 3rd-4th refresh. There is a well-known restart bug: question1, question2, though it happens rarely.
• Language-level bugs. When I used static inner classes, I always needed to restart the server on a change. Though there are no problems with building, language usage is limited for me
• startup time, build time, application size (70 megs for a small app), memory usage
• remote debugging only, IDE debugging is very unstable

---

Has it overcome its buggy start?

It's still horrible. I do not know their start, but migration from Grails 2 to Grails 3 is still nightmare and they are breaking more than they solve.

Does it really confer rapid development benefits?

I spent one hour making Grails' tests to output something in console(it doesn't work out of the box), even in Java you will not spend such amount of time to output something from tests.

Does it perform for real world production apps?

I still do not know a single famous company who is building something with Grails.

Is the Eclipse plug-in better than it was and fit for purpose?

I've no idea why anybody's still using Eclipse, but IntelliJ support for Grails 3 is just unusable.

So, answering the main question:

Is Grails (now) worth it?

If you can not afford the Microsoft Access license, maybe. For real projects I would stay away from Grails. It's just a stillborn child, in fact.

참고URL : https://stackoverflow.com/questions/2055396/is-grails-now-worth-it