Telerik UI는 jQuery를 사용하여 클라이언트 측 UI를 제어합니다

https://stackoverflow.com/questions/428376

06-07-2019
|

문제

외부를 향한 웹 앱을 위해 UI를 처리하는 방법을 결정하려고합니다. 외부이기 때문에 페이지 부풀어 오르는 페이지로 인한 대기 시간이 문제가 될 수 있습니다.

나는 과거에 jQuery를 사용했으며 지금 Telerik 컨트롤을 평가하고 있습니다. 나는 StackoverFlow의 일부를 포함하여 Telerik 컨트롤에서 많은 권장 사항을 보았습니다. 실제로 그들은 상당히 완전한 용도로 보인다. 또한 jQuery보다 해당 컨트롤을 사용하여 응용 프로그램을 훨씬 더 빨리 개발할 수 있다는 것은 의심의 여지가 없습니다. 그러나 나는 그들이 내 페이지에 너무 많은 부풀어 오른 것을 걱정합니다.

이러한 컨트롤의 성능을 순전히 jQuery 구현과 비교 한 경험이 있습니까? 구체적으로,

Telerik의 RadscriptManager가 MS Ajax ScriptManager보다 더 나은가요?
Telerik Controls에서 일반적으로 성능 문제가 있습니까?
Radgrid의 그리드 기능에 가까운 jQuery에 대한 플러그인이 있습니까?

다른 관련 정보도 유용 할 것입니다.

해결책

나는 수년간 Telerik과 JQuery를 사용했습니다. "Full Featured"는 일반적으로 필요하지 않은 기능, 최적화하기 어려운 최종 페이지와 동일합니다. Telerik을 떨어 뜨리고 jQuery와 같은 베어 메탈 프레임 워크를 사용하십시오. 필요한 특정 기능을 구축 할 수 있으며 절대 돌아 가지 않을 것입니다. Telerik 또는 ComponentArt와 같은 등장 된 UI 스위트 중 다수는 매우 유혹적이지만 많은 나쁜 프로그래밍을 장려한다고 생각합니다.

예를 들어 .... 그리드에 드래그 앤 드롭 가능 열이 있어야합니까? 아마 그렇지 않을 것입니다. 사용자가 열 환경 설정을 레이아웃 할 수있는 디자인 영역을 갖추고 그리드가 칙칙하고 가벼운 주 뷰를 갖는 것이 좋습니다. 사용자가 모든 페이지보기에 사용하지 않는 추가 기능의 메가 바이트를 렌더링하지 마십시오.

다른 팁

여기에 좋은 토론. 일부 설명 :

Telerik은 내부적으로 jQuery를 사용하고 (MS가 지원할 수있게 될 것임) 많은 컨트롤에 대한 클라이언트 측 기능 (클라이언트 측 코드 감소)을 향상시킵니다.
JQuery는 JavaScript 개발에 적합한 클라이언트 측 라이브러리입니다. 그러나 접근성을 해결 해야하는 경우 모든 기능에 대한 JavaScript에 의존하기 때문에 jQuery UI 구현이있는 개울입니다. Telerik의 고유 한 장점은 클라이언트 측 및 서버 측을 모두 렌더링 할 수 있다는 것입니다. 즉, JavaScript가 활성화되지 않은 클라이언트를 지원할 수 있습니다.
많은 Telerik Controls의 경우 a) 기능을 비활성화하여 (내부로드에 필요한 스크립트로드로 인해) 또는 B)를 사용하여 스크립트 콤바이너를 사용하여 클라이언트 측 코드의 영향을 크게 줄여서 페이지에서 추가 코드를 제거 할 수 있습니다. 압축기.

그러나 오랫동안 웹 개발자이기 때문에 항상 사람들이 작업에 적합한 도구를 사용하도록 권장합니다. Radcontrols 또는 Accesiblitity 지원 또는 광범위한 문서 (앱을 상속받을 사람을 돕기 위해)의 강력한 기능이 필요하지 않은 경우 사이트에 사용하지 마십시오. 필요한 것이 기본 UI 만 있으면 jQuery는 괜찮을 수 있습니다. 그러나 내가 찾는 경향은 개발자가 추가 작업을 수행하지 않기 위해 사용자에게 고급 기능을 제공 할 수있을 때, 사용자에게 최종 제품에 훨씬 더 깊은 인상을 받고 훨씬 쉽게 찾을 수 있다는 것입니다. 사용.

그리고 무엇보다도 대부분의 경우 회사/고객에게 가치를 창출함으로써 기억하십시오. 응용 프로그램- UI 구성 요소가 아닙니다. 따라서 바퀴를 다시 발명할만한 충분한 이유가 없다면, 일반적으로 직면하고있는 문제를 해결하기 위해 이미 제작되고 테스트 된 것을 사용하는 것이 가장 좋습니다.

도움이되기를 바랍니다. -todd

Brian C (et al)가 직면 한 "Bugginess"및 기타 도전과 관련하여 여기서는 추가 설명이 필요하다고 생각합니다. 개발자 옹호자로서, Telerik 컨트롤이 완벽한 필사자가 작성한 소프트웨어는 완벽하다는 척도하지 않을 것입니다. 중요한 것은 버그가 어떻게 해결되는지입니다.

너무 자주 사람들은 회사 (또는 오픈 소스 프로젝트)가 너무 늦을 때까지 버그를 해결하는 방법을 간과합니다. jQuery, Telerik 또는 Microsoft를 사용하는 도구에 관계없이 결국 버그에 부딪 칠 것입니다. Telerik이 탁월한 경향이있는 곳은 이러한 문제에 대한 빠른 수정을 제공하고 가능한 한 생산성을 높일 수 있도록 매우 철저한 지원을 제공하고 있습니다. 문제가 있으면 Telerik-이를 해결하도록 도와줍니다. 다른 회사, 특히 오픈 소스를 사용하면 항상 보증은 아닙니다.

그냥 기억하십시오 : 어떤 도구를 사용하든 버그에 직면하게됩니다. 문제에 대응할 수있는 지원이 포함 된 도구를 선택하고 매우 빠르게 수정하십시오. 그리고 나는 내 관점이 불가피하게 편향되어 있다는 것을 알고 있기 때문에 StackoverFlow의 다른 사람들이 Telerik의 지원 품질을 확인하거나 거부하게 할 것입니다.

Telerik Controls는 약간 부풀어 오른 것처럼 보이지만 많은 노력없이 jQuery에서 비슷한 것을 달성 할 수 있을지 의심됩니다.

그것은 당신이 견딜 수있는 금액에 달려 있습니다. 인트라넷 애플리케이션이라면 실제로 중요하지 않지만 외부 대면을 지정하면 문제가 될 수 있습니다. 실제로 사용자의 평균 연결 속도와 컴퓨터/브라우저의 속도에 따라 다릅니다. 궁극적으로 컨트롤을 실행합니다.

또 다른 중요한 질문은 다음과 같습니다. jQuery보다 훨씬 적은 독점 도구 세트에서 웹 응용 프로그램을 표준화 하시겠습니까? 나는 jQuery가 곧 사업에서 벗어날 것이라고 의심합니다.

나중에 다른 사람을 돕는 경우, Telerik 도구를 버렸고 지금은 jQuery를 독점적으로 사용하고 있습니다. 내가 할 수없는 일에 빠지면 볼 것입니다. Telerik 도구에 실망했습니다. 나는 그들에 대해 너무 많은 좋은 것을 들었지만 그들은 나에게 그렇게 잘 작동하지 않았습니다. Telerik 도구를 평가할 때 찾은 내용은 다음과 같습니다.

Telerik Ajax 도구에는 마스터/컨텐츠 페이지 설정을 처리하는 데 문제가 있습니다. 그들은 포럼에서 이것을 인정하고, 나는 그것에 대해 노력하고 있다고 생각합니다. 그래도 나에게는 꽤 문제가 있습니다.
나는 문서가없는 것처럼 보이는 예상치 못한 행동과 단점을 많이 보았습니다. 예를 들어, web20 스킨과 데코레이터를 사용할 때 필드 세트의 둥근 모서리는 Ajax를 할 때 모두 지옥으로갑니다.
Telerik 도구는 내 Dev 기계를 약간 느리게하고 환경에 문제를 일으키는 것처럼 보입니다. 나는 사고 나 메모리 위반이 거의 없었 으며이 도구를 사용하는 동안 이틀 만에 4 개를 가졌습니다. 아마도 그 전에 마지막으로 한 달이 지났을 것입니다.
따라서 jQuery가 자유롭고 가벼우 며 선택이 쉬웠다는 사실과 모든 것을 결합하십시오. 처음에는 조금 더 오래 걸릴 수 있지만 결과는 결국 훨씬 나아질 것입니다.

UI 요구 사항은이 결정에 가장 큰 영향을 미칩니다. Telerik 컨트롤이 기능 측면에서 jQuery와 비교 될 수 있다고 생각하지 않습니다. 데이터를 표시하기 위해 서버 측 컨트롤이 필요한 경우 다른 경쟁 컨트롤에 대해 Telerik을 평가하십시오.

나는 Telerik 컨트롤을 사용하고 소스 코드에 대해 지불했으며, 사업을 중단하는 것에 대해 소스 코드를 고려할 때 큰 관심사는 아닙니다. 나는 공개 웹 사이트에서 Telerik Controls를 사용한 특정 경험이 없지만 주저하지 않을 것입니다. 컨트롤에 없었던 추가 기능을 위해 jQuery를 사용하도록 때때로 지시를 받았습니다.

제가 가지고있는 한 가지 문제는 컨트롤을 사용 하여이 기능을 모두 코딩하지 않기 때문에 (Telerik만이 아니라) 모든 종류의 재미있는 물건을 페이지로 끌고 삭제하는 것이 정말 쉽다는 것입니다. 각 페이지에 처리를 추가하십시오. 즉, 최소한의 사용을 최소한으로 유지하면 손으로 구분 된 jQuery 구현보다 더 부풀어 오르지 않을 것이라고 생각합니다.

우리는 인트라넷 제품에 Telerik 편집기를 사용하며, 이전 편집기보다 작업, 사용자 정의, 업그레이드 등이 훨씬 더 좋다고 말해야합니다.

고급 기능 및/또는 더 복잡한 제어가 필요한 경우 그리고 Telerik은 이것을 제공합니다. jQuery UI가 제공 할 수있는 기본 UI 기능 만 있으면 해당 특정 부품에 jQuery를 사용하십시오.

하나 또는 다른 사람과 함께 갈 필요가 없습니다. 도구를 혼합하여 작업을 완료하십시오.

RadscriptManager는 MS AJAX ScriptManager와 다릅니다. enableScriptCombine = "True"속성이 있기 때문에 Telerik 컨트롤이 사용하는 모든 JavaScript 파일을 하나의 .js 파일로 결합하여 성능을 향상시킬 수있는 EnableScriptCombine = "True"속성이 있기 때문입니다.

원래 RAD 편집기는 꽤 느리게 달렸습니다. 그러나 최신 버전은 훨씬 빠릅니다. 또한 그들은 컨트롤을 개선하기 위해 지속적으로 노력하고있는 직원에게 지불했습니다.

나는 Radgrid에 가까운 것을 알지 못합니다. 꽤 강력합니다. 나는 지금 인트라넷 앱에서 그것을 사용하고 있으며 지금까지 빨리 실행됩니다. 나는 그 모든 기능, 그룹 별, Excel로 내보내기 등을 사용하고 있습니다.

즉, 외부 사용을 위해 인터넷 응용 프로그램을 만들고 있다면 Telerik에 jQuery를 사용할 것입니다. 그렇게하면 더 많은 통제력이 있습니다.

Telerik은 고객 측에 jQuery를 사용할 것이라고 생각했다고 생각합니다.

Telerik은 이제 Radgrid에 대한 고객 측 지원에 더 많은 시간을 할애하기 시작했습니다. 지금까지 나는 그리드에 실망했습니다. Postbacks 및 Viewstate를 기반으로 C#의 모든 것을 다시 그리는 서버 컨트롤 및 JavaScript에서 제어의 일부를 다시 작성하는 클라이언트 측 컨트롤 용 서버 컨트롤을위한 하나는 본질적으로 2 개의 코드 기반을 유지해야하기 때문에 기분이 나쁩니다. (C# 코드의 포트와 같은 종류). 그것은 그들을위한 많은 일의 지옥이고 지금까지 나는 그것이 불완전하다고 생각합니다.

예를 들어 고객 입장에서 그리드의 현재 버전에 대한 지원 (ASP.NET AJAX 2008.3.1105.35)에는 다음이 포함되지 않습니다.

그룹화 표현식
페이지 크기 증가
다른 호출기 스타일 NextPrev
숨겨지기/열 표시
AllowNaturalSort="false"
순수한 클라이언트 측 분류 (즉, 브라우저에서 오른쪽)

전통적인 Postback/ViewState 렌더링으로 Telerik 컨트롤을 사용하는 것이 행복하다면 경쟁 할 수있는 jQuery 그리드가 없다고 말합니다.

나는 보통 이런 것들에 대해 게시하지 않지만 이것에 저항 할 수 없었습니다. 나는 Telerik을 통해 jQuery / jQuery UI와 함께 갔다. 나는 그들이 데모 페이지에서 가지고있는 것을 정말로 좋아했습니다. 그런 다음 나는 그것을 작동 시키려고 노력했습니다. 나는 리본 바에 어려움을 겪고 버그를 보여 주었다. 그들은 곧 해결 될 예정이었다. .. 그것은 아니었다 .... 다음 릴리스 ... 그렇지 않았다. 마침내 그들은 베타 버전을 가지고 그들을 위해 테스트 해달라고 요청했습니다. 그들의 물건은 확실히 좋아 보이지만, 나는 단지 작동하지 않는 것들을 다룰 수 없었습니다.

나는 약 6 개월 동안 jQuery / jQuery UI를 사용해 왔으며 나는 그것을 좋아합니다. 사용하기 쉬운. 경량. 그것이 말하는 것을합니다. 전체적으로 Telerik만큼 특징이 아니라 이해하기 쉬우 며 몇 가지 스크립트로 프로젝트에 넣을 수 있습니다. 나는 Themeroller도 정말 좋아합니다.

나는 3 년 동안 컨트롤을 위해 Telerik을 사용해 왔습니다. 나는 마침내 내가 아이디어에 사랑에 빠졌다는 것을 깨달았지만 제어 자체는 매우 버그가 많고 구현하기가 성가 시며 결국 자신을 구축해야 할 시간이 더 많이 들었습니다. Telerik을 사용하지 않는 것이 좋습니다.

나는 둘 다 함께 일했다 jQuery 그리고 Telerik. Telerik 공식 사이트의 데모에서 매우 화려하지만 사용할 때는 매우 무겁고 느낍니다. 와 함께 jQuery 귀하의 요구를 해결하지만 더 많은 시간이 필요한 가볍고 효율적인 코드를 작성할 수 있습니다. 성능 측면에서 클라이언트 브라우저 대신 서버에서 초기 HTML 결과를 렌더링하는 것이 좋습니다. (예 : 큰 그리드)

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow