Django 인기의 역사
Django를 가장 인기있는 Python 웹 프레임 워크 ..로 만든 일련의 이벤트는 무엇입니까? 여러 다른 프레임 워크가 존재하지만.
참고 :이 질문은 논쟁 적이거나 대립적인 것이 아닙니다 . 나는 단지 그것의 실제적인 인기로 이끄는 (객관적인) "사건의 순서"를 물었다. 소프트웨어 수용의 역학 관계를 알고 있으므로 누구도 기술 우월성에 대해 논쟁을 벌일 생각은 없습니다.
나는 몇 가지 요인이 있다고 생각하는데, 그 조합은 개별 가중치의 합보다 더 컸습니다.
하나는 단순히 타이밍입니다. Django는 Rails의 첫 번째 큰 물결이 급증하면서 바로 나타났습니다. 그래서 즉시 "Rails에 대한 Python의 대답"으로 묘사되었습니다. 그 결과 거의 처음부터 프로젝트에 대한 눈알이 많지 않았습니다. Adrian이 시카고에서 열린 "Snakes and Rubies"밋업에 있었고 Rails와 Django에 대한 나란히 대화에 참여하게 된 사실은 그에 큰 도움이되었습니다.
또 다른 요소는 Django가 항상 단일 패키지 설치라는 것입니다 (정답은 아닙니다 : Python 2.5 이상을 사용하고 SQLite를 사용하지 않는 한 데이터베이스 어댑터가 여전히 필요하지만 충분히 가깝습니다). 컴포넌트 선택을 개발자의 손에 맡기는 데 초점을 맞춘 비 Zope 대안은 기본 튜토리얼을 수행 할 수있는 지점에 도달하기 위해 훨씬 더 많은 작업이 필요했습니다. ORM을 찾아야합니다. 템플릿 언어 등을 사용하고 모두 설치하고 구성합니다. 그것은 수년에 걸쳐 훨씬 나아졌지 만 그에 대한 기억이 여전히 효과가 있다고 생각합니다.
그리고 Django는 (내가 그렇게 말할 수 있다면) 오픈 소스 프로젝트의 일반적인 표준보다 훨씬 높았으며 시간이 지남에 따라 향상되었습니다. 이 튜토리얼은 모든 결함에 대해 Django를 유용하게 만드는 여러 가지 핵심 사항에 대해 언급했으며 나머지 문서는 API 참조와 중요한 "방법"비트를 필요에 따라 혼합하여 항상 좋은 품질을 유지했습니다. 이것은 좋은 기본 경험을 제공하고 사후 학습 곡선 (항상 Zope를 괴롭히는 것)을 돕습니다.
나는 또한 옳든 그르 든-Pylons 또는 Werkzeug가 WSGI 및 Python 웹 생태계에 대해 이미 알고있는 숙련 된 개발자에게 정말 더 낫다는 인식이 있다고 생각합니다. 그들이 기존의 즐겨 찾는 라이브러리를 가져 와서 함께 연결하기위한 강력한 선택이되는 경향이 있다는 사실이 이것의 원천이라고 생각하며 아마도 Django의 통합 접근 방식에 대해 새로운 사람들을 유혹 할 것입니다. 물론 반대로 장고를 시도하기 전에 더 많은 것을 배우는 것이 더 나은 많은 사람들이 그렇게하지 않는다는 것입니다.)
마지막으로 Django가 마케팅 된 방식에 대해 말할 것이 있다고 생각합니다. 즉, 장고가 실제로 오랫동안 마케팅 되지 않았 거나 적어도 Rails가 마케팅되었다는 의미에서는 그렇지 않다는 것입니다. Django 1.0이 출시 될 때까지 "마케팅"노력은 대부분 사람들이 블로깅을하고 (그리고 사람들이 그것을 약간 낮추도록 요청받은 주목할만한 사건이있었습니다) PyCon에서 이야기 한 다음 대부분 프레임 워크를 개선하고 멋진 것들을 구축하는 것으로 구성되었습니다. 결과가 스스로를 대변하게합니다. 물론 1.0 이후의 세계에서는 DSF와 DjangoCon, 비즈니스 지향 컨설턴트가 교육 세션과 많은 책과 나머지 모든 것을 수행하고 있지만, 그것은 여전히 완전히 새로운 것입니다.
저는 Rails와 마찬가지로 반발이있을 것으로 예상하고 실제로는 한동안 양조 중이며 이미 시작되었다고 생각합니다. 하지만 지금까지 제가 여기에 나열한 요소는 적어도 Django가 처음 출시 된 이후로 보여준 일관되고 꾸준한 인기의이면에있는 주요 요소라고 생각합니다.
2005 년에 Django가 등장했을 때 많은 Python 웹 프레임 워크가 이미 존재했습니다. 실제로 그 당시에는 Python이 "키워드보다 웹 프레임 워크가 더 많은 언어"라는 농담이 이미 진행되고있었습니다 (그리고 Guido는 Py3k에서 수정하겠다는 제 제안을 거부했습니다. 더 많은 키워드 추가). 이제 "django"자체는 검색어로서 약간 모호합니다 (또한 Woody Allen 영화 등에서 영감을 얻은 인기 기타 연주자의 이름이기도합니다). 그럼에도 불구하고 검색에 "python"을 추가하여 다른 의미를 제거합니다. 예를 들어이 그래프 에서 볼 수 있습니다.다른 고전적인 Python 웹 프레임 워크 인 Zope와 비교하여 상대적 인기가 어떻게 변했는지. 2008 년 2 분기가 시작될 무렵 놀라운 급증과 함께 전분기 대비 대부분 꾸준한 성장세를 보였습니다. 이는 Google이 App Engine을 발표 한 날짜와 일치합니다 (이 경우 인과 관계를 증명하는 것은 불가능하지만 우연의 일치는 적어도 흥미로운 ;-).
App Engine은 기본적으로 커스텀 C 코딩 된 구성 요소에 크게 의존하거나 본질적으로 '높은 관계형'기능을 요구하는 모든 Python 웹 프레임 워크를 배제합니다. 순수한 Python 코드로 잘 실행되는 것 중에서 Django는 아마도 App Engine이 가장 직접적이고 눈에 띄게 지원하는 것일 것입니다. 그러나 이것은 장고의 근본적인 건전한 성장 추세에 추가 된 단지 향상 일뿐입니다. 이러한 추세에 대한 설명 (실제로 App Engine 팀과 Django를 잘 지원하기로 한 사용자의 결정)은 Django 자체에 고유 한 특성에 있어야합니다.
Django는 Pylons, TurboGears, Werkzeug, & c와 같은 대안에 비해 "너무 마술 적"이거나 "너무 모 놀리 식"이라는 비판을 받기도합니다 (특히 후자의 경우 포함). , 내가 가장 좋아하는 ;-), 더 투명하고 특정 구성 요소 (ORM, 템플릿, & c)를 쉽게 교체 할 수 있습니다. 그러나 Django의 인기는 서버 측 웹 사이트 및 앱 개발에 관심이있는 대부분의 사람들에게 이러한 Django 디자인 선택이 긍정적으로 인식되고 있음을 알려줍니다. Django는 매우 풍부하고 잘 통합 된 프레임 워크로 간주됩니다 (그리고 많은 추가 기능이 있습니다. 온과 기여한 "플러그인", 그러나 그것들은 그 우위의 원인보다 더 많은 결과입니다).
시작의 용이성, 자동 "관리자 페이지"등-Django 는 매우 풍부하고 복잡한 사이트 / 앱을 만들고 많은 기술과 약간의 작업으로 독특하거나 고유 한 요구 사항을 수용하도록 구부릴 수 있다는 사실 - 아마도 "킬러 기능"일 것입니다. Werkzeug를 최상으로 사용하려면 HTTP 및 WSGI를 이해하고 Python 기반 웹 사이트 및 앱 개발자 (예 : Rails 사용자 또는 다음의 사용자)와 같이 선호하는 저장소 및 템플릿을 선택하고 통합해야합니다. 훨씬 더 인기있는 PHP!-)는 반드시 그 어떤 것도 할 필요는 없지만 대부분의 애플리케이션 도메인에 집중할 수있는 환경을 위해 "마인드 쉐어로 투표"하고 있습니다. 나는 그들이 아마도 요점이 있음을 인정해야 할 것입니다 .-).
Django의 인기에 대한 세 가지 이유를 생각할 수 있습니다. 그 중 하나만 다른 답변에서 다루었습니다.
선적 서류 비치. 다양한 기술 수준에서 체계적이고 포괄적이며 접근하기 쉽습니다.
디자인. 관리자, 오류 페이지 및 프로젝트 사이트의 시각적 디자인은 대부분의 오픈 소스 프로젝트에서 볼 수있는 디자인 수준보다 훨씬 높습니다.
커뮤니티 지원. World Online의 팀을 시작으로 Django는 초기에 영향력있는 전도사 몇 명을 선택했습니다. Jeff Croft의 Django for Non-Developers와 같은 블로그 게시물의 중요성을 과도하게 언급 할 수 있을지 모르겠습니다 (제 생각에 그것이 제목이라고 생각합니다).
"내 개인적으로 가장 좋아하는 것, 그리고 오랫동안 개인적으로 좋아할 것으로 기대되는 것은 Django라는 이름입니다."-Guido Van Rossum on FLOSS 주간 에피소드 11, 2006 년 8 월 4 일 방영
[여기를 클릭하세요] (인터뷰의 마지막 1/3을 들어보세요)
이것이 도움이되었다고 생각하십니까? 또는 적어도 Google이 AppEngine을 위해 선택한 이유는 무엇입니까?
물론 django 커뮤니티 (개발자 포함)는 많은 일을 제대로하고 있습니다. 예 (링크의 일부 분석) :
모듈성 향상 : [여기를 클릭]
kick ass documentation 여기를 클릭하십시오
또한 사람들이 기여하고 싶어하는 커뮤니티에 대해 제가 아직 언급하지 않은 부분이 있습니다. 여기를 클릭하세요.
물론 Django가 이상 치가되는 모든 것 : 여기를 클릭하세요.
Django의 인기에 대해서는 의문의 여지가 없습니다.
In my case, I'd bought the TurboGears book, and struggled through its inconsistencies and haphazard route to explaining things. Then I got the Django book, and voila! My first for-pay project was created while working my way through the sample project in the book. That plus the online documentation sealed the deal. For me, it was simple: Documentation, documentation, documentation.
I noticed that it often got promoted as being the Ruby on Rails equivalent in Python. It's also has a connection to Google (Google hosts Django events, and supports it in their App Engine). A web framework being endorsed by Google has to amount for something. :)
At least for me, an important factor was that Simon Willison and Adrian Holovaty were already well known players in the "Web Standards" scene, as well as Jeff Croft later.
That wasn't only a quality seal, but also made Django very web-friendly, with its respect for HTTP, markup, and even the quick and dirty, "print debugging" way of working that people coming from PHP were used to.
I might be heavily wrong here, no data to back this up, but I feel that Django gained a lot more traction from people coming from PHP, as opposed to Rails which got a lot of conversions from Java/.NET.
As others already noted, the documentation is way above average. The best I've seen, as far as I recall.
The fact that there were several high volume sites already using Django (i.e. lawrence.com etc...) - even by the 0.96 days - helped me convince management it was safe to use. Things like Pylons and Turbogears really did not have that.
As for Django's popularity over time (the literal meaning of your question title, if not quite your actual question), have a look at the google trend.
참고URL : https://stackoverflow.com/questions/1515324/history-of-djangos-popularity
'program story' 카테고리의 다른 글
jQuery 날짜 선택기-과거 날짜 비활성화 (0) | 2020.09.15 |
---|---|
Google지도 API v2의 기본 위치 및 확대 / 축소 수준을 어떻게 설정합니까? (0) | 2020.09.15 |
PowerShell의 파일 이름에서 경로 및 확장자 제거 (0) | 2020.09.15 |
코드를 컴파일하지 않는 Android Studio 3.1 '실행' (0) | 2020.09.14 |
부분 클래스 파일에 대한 명명 규칙 (0) | 2020.09.14 |