2012-02-24 42 views
43

Tôi đã chọn sproutcore làm khuôn khổ ngay trước khi Ember được tách ra từ sproutcore. Tôi không chắc chắn về cách nào để đi và một chút thất vọng trong sự pha loãng rõ ràng của những nỗ lực gây ra bởi sự phân mảnh - như hiếm khi nào dẫn đến những điều tốt hơn. Những nỗ lực của Sproutcore 2.0 (hiện nay là Ember) dường như đang đi đúng hướng mô-đun hóa và tái sử dụng các thành phần javasript khác (jQuery), tuy nhiên nó thực sự không rõ ràng từ một quan điểm bên ngoài tại sao hai nỗ lực phải tách ... không thể t chúng tôi có mã mô-đun, và một mô-đun thư viện widget quá?Sự khác biệt giữa Sproutcore và Ember

Các câu hỏi chính là:

  1. sự khác biệt hiệu quả giữa hai nỗ lực là gì?
  2. Lịch sử chia tách là gì?
  3. Tương lai mọc lên là gì, nó sẽ đi đâu bây giờ?
  4. Ember có phát triển để thay thế hoàn toàn cho sproutcore không?
+0

Tôi có những câu hỏi đó. Mọi người đang nói, nếu bạn đang xây dựng một ứng dụng giống như máy tính để bàn, hãy sử dụng Sproutcore 1.x để ứng dụng web đi với Ember (trước đây là Sproutcore 2). Tôi nghĩ rằng một bộ phận như vậy không có ý nghĩa, không phải cả hai đều dành cho RIA phía khách hàng? Sự khác biệt thực sự duy nhất đối với tôi là trong khi Ember dễ làm việc hơn, nó vẫn đang phát triển và bỏ lỡ rất nhiều tính năng. –

Trả lời

78

Là một người có cả ứng dụng Sproutcore và ứng dụng Ember gần một buổi giới thiệu sản xuất, tôi sẽ xem xét các câu hỏi của bạn (được sắp xếp lại để rõ ràng). Tất cả những điều dưới đây là những gì tôi đã quan sát mà không có kiến ​​thức bên trong. Một chút của nó là suy đoán, vì vậy tôi đã kích hoạt chế độ wiki trên câu trả lời này, để những người thông báo hơn có thể sửa các chi tiết.

Lịch sử chia tách là gì?

Dưới đây là những gì tôi đã chắp ghép:

SproutCore được tạo ra bởi công ty Sproutit Charles Jolley như cơ sở sản phẩm phòng thư tín của họ trong năm 2007. Jolley sau gia nhập Apple và Sproutcore được sử dụng để xây dựng các ứng dụng web gốc cho Mobile Me. Nhiệm vụ là tái tạo lại trải nghiệm của các ứng dụng Mac như Mail và iCal, và nỗ lực đó vẫn tiếp tục trên Sproutcore hôm nay với iCloud.

Xe đẩy rời Apple và thành lập một công ty có tên Strobe ở San Francisco với tầm nhìn một phần để tận dụng Sproutcore. Nhóm nghiên cứu tại Strobe đã quyết định rằng Sproutcore không phù hợp với nhiều trường hợp sử dụng Web 2.0, và quá nhiều đề xuất cho tất cả các nhà phát triển, vì vậy họ bắt đầu nỗ lực hướng tới Sproutcore 2. Mục tiêu của Sproutcore 2 là mô đun và một phương pháp tiếp cận nhận thức HTML dễ tiếp cận hơn đối với các nhà phát triển web ở mọi nơi. Lực kéo đầu của Backbone là một phần của phân tích này.

Sau khi đấu tranh để di chuyển mã nguồn Sproutcore về hướng nhìn này, nhóm Strobe đã quyết định bắt đầu làm mới với Sproutcore 2 (tên mã là Amber bên trong). Charles đã viết cốt lõi Run Loop và mã quan sát-giá trị quan trọng. Yehuda Katz và Tom Dale là những nhà phát triển Strobe hàng đầu trong dự án. Tầm nhìn vào thời điểm đó là Strobe và cộng đồng cuối cùng sẽ chuyển qua hầu hết các tính năng và chức năng từ Sproutcore 1.x đến Sproutcore 2.

Những nỗ lực kinh doanh nhấp nháy không mang lại kết quả mong đợi, và công ty cân nhắc các tùy chọn của nó, cuối cùng quyết định mua lại tài năng Strobe của Facebook. Trước khi điều này xảy ra, một số nhân viên của Strobe, bao gồm cả Katz và Dale, đã tách ra để thành lập một công ty mới có tên là Tilde.

Dấu ngã đã quyết định tiếp tục phát triển Sproutcore 2, nhưng đổi tên (thành Amber.js và sau đó là Ember.js) và mục tiêu của dự án. Họ đã bỏ mục tiêu dài hạn về khả năng tương thích ngược với Sproutcore. Họ đã bỏ hỗ trợ cho bất kỳ loại thư viện tiện ích xem nào và tập trung vào trường hợp sử dụng HTML/CSS với việc tích hợp chặt chẽ ràng buộc dữ liệu với ngôn ngữ khuôn mẫu Handlebars.

Kể từ khi giải thể Strobe, quản lý của Sproutcore 1.x đã được chuyển từ Jolley đến Tyler Keating và cộng đồng đã tập trung lại vào việc làm sạch Sproutcore 1.x, ở một nơi không thoải mái trong một thời gian khi ý tưởng của Sproutcore 2 đã lờ mờ.

Sự khác biệt hiệu quả giữa hai nỗ lực là gì?

Điểm tương đồng trong các dự án là chúng có các mô hình đối tượng rất giống nhau. Họ cũng có hệ thống sở hữu, quan sát và ràng buộc tương tự.

Sproutcore bao gồm thư viện các tiện ích chế độ xem như thanh công cụ, chế độ xem danh sách, chế độ xem lưới, nút và hệ thống theming, và tập trung vào xác định lớp xem qua Javascript và vị trí tuyệt đối do thư viện quản lý. Nó rất mạnh mẽ để tạo các ứng dụng kiểu máy tính để bàn trên web.

Ember có dấu chân nhỏ hơn. Nó có tính năng tích hợp chặt chẽ với Handlebars. Nó là một thay thế cho xương sống cho nhiều dự án. Nó nhằm mục đích cung cấp một kiến ​​trúc ứng dụng tiêu chuẩn cho các ứng dụng phía máy khách và loại bỏ mã soạn sẵn.

Những khác biệt này có thể sẽ dẫn đến việc phân chia khung, mặc dù đã có một số cân nhắc áp dụng cùng một lõi. Trong trường hợp đó, Sproutcore sẽ sử dụng thư viện "kim loại" của Ember và có lẽ là các thư viện lõi khác).

Tương lai của Sproutcore là gì?

Chuỗi này có vài phút từ buổi họp mặt của người đóng góp gần đây.

https://groups.google.com/group/sproutcore/browse_thread/thread/aacf00a6047a866e#

Lộ trình ngắn hạn là tập trung vào củng cố các tài liệu tiếp thị, trình diễn, và codebase. Nhóm gần đây đã phát hành Sproutcore Showcase. Có sự đồng thuận chung về việc thay thế abbot, các công cụ xây dựng của Ruby cho Sproutcore, với một giải pháp dựa trên Javascript (node.js), hiện đang được phát triển tích cực. Ngoài ra còn có một mong muốn cho ít hơn "hợp nhất" mã từ các công ty như Apple và phát hành thường xuyên hơn. Sproutcore 1.8 gần đây đã được phát hành.

Ember có phát triển để thay thế hoàn toàn cho sproutcore không?

Không có khả năng. Nhóm cốt lõi Ember đã rõ ràng rằng họ không có ý định phát triển cá nhân những tính năng còn thiếu. Có thể các thành viên cộng đồng có thể phát triển những dự án đó thành các dự án riêng biệt - flame.js là nỗ lực đầy tham vọng nhất cho đến nay. Lựa chọn thiết kế của Ember giúp dễ dàng tích hợp với các dự án như jQuery UI, do đó, việc thay thế đầy đủ có thể hoặc không cần thiết.

+2

Trên thực tế SproutCore được tạo ra tại công ty của Charles Sproutit làm cơ sở cho sản phẩm Mailroom của họ vào năm 2007 trước khi Charles gia nhập Apple. Khác với chi tiết nhỏ đó, +1 tốt ạ. Được viết độc đáo. –

+0

Cảm ơn, vì sự điều chỉnh đó Roy. Tôi đã cập nhật câu trả lời cho phù hợp. –

+0

Cảm ơn bạn đã giải thích chi tiết. Khi đi ra ngoài trên một chi, hãy chọn một khung công tác, một người thích biết nó ổn định và có sự hỗ trợ cộng đồng lâu dài - jQuery là một ví dụ tốt. Những sự kiện này chắc chắn là không may, và đặt nghi ngờ trong tương lai của cả hai Sproutcore và Ember trong một lĩnh vực nhiều nỗ lực duluted. Tất nhiên những gì hầu hết mọi người muốn là cả một cơ sở mã mô-đun nhỏ và dễ sử dụng widget UI và theming (với tùy chọn tùy biến hoặc kéo nó ra tất cả cùng nhau). –

13

1) Dòng chính thức là Sproutcore dành cho RIA và Ember.js dành cho các ứng dụng "kiểu web". Vì vậy, khi bạn nhìn vào iCloud nghĩ Sproutcore và khi bạn nhìn vào Twitter nghĩ rằng Ember.js.

Từ quan điểm kỹ thuật, Ember.js tập trung vào mã được mô đun hóa hơn và được gọi là "mẫu ngữ nghĩa" cho chế độ xem. Sproutcore là nguyên khối hơn.

2) Tôi không chắc ai thực sự biết. Nếu bạn nhìn vào dòng thời gian, Charles Jolley rời Apple để thành lập một công ty gọi là Strobe, phát triển một nền tảng đầy đủ để phát triển ứng dụng. Strobe thuê Yehuda Katz và những người khác, những người bắt đầu làm việc trên slimming xuống SC vì vậy nó sẽ chạy tốt hơn trên các thiết bị di động. Sau khoảng một năm, Yehuda rời khỏi để thành lập công ty Tilde, và một tháng sau đó Facebook đã mua Strobe trong những gì được coi là một sự mua lại tài năng.

Vì vậy, hãy diễn giải như bạn muốn.

3) Đây là một câu hỏi hay. Recently there was a meetup and several things were discussed. Những điểm mấu chốt thảo luận là:

  • SC vẫn còn sống và đá
  • Cải thiện tài liệu hướng dẫn (chúng tôi đã được nghe rằng trong một thời gian).
  • Giữ những phần tốt mã mà đã được giới thiệu bài 1.4.5 trong sự phát triển của SC2 và thoát khỏi hoặc di chuyển đến các module tùy chọn thứ khác (như Templates)
  • mới javascript dựa trên công cụ xây dựng
  • vải hoàn toàn mới dựa trên lớp xem, được gọi là Blossom.
  • Một số loại nền tảng/sự ủng hộ của công ty đối với SC

Có lẽ những người khác rằng tôi đã bỏ lỡ

4) Chắc chắn không phải là một sự thay thế, mặc dù bạn có thể sử dụng bất kỳ khuôn khổ để xây dựng bất kỳ ứng dụng (đó là tất cả javascript , sau khi tất cả).

+0

Chỉ cần thêm điểm nhanh, có một tài liệu/trang web "chạy nước rút" vào cuối tuần này để SC sửa một số thứ bị hỏng và giúp các nhà phát triển mới hoạt động nhanh chóng bằng các công cụ phù hợp. Bạn có thể đọc thêm một chút về việc chạy nước rút ở đây: http://blog.sproutcore.com/sprint-towards-1-8-release/ –

+0

Vì vậy, tôi đã dành một chút thời gian đọc các nút họp mặt và nhìn vào Blossom ... Blossom trông giống như hướng đúng, tuy nhiên tôi lo ngại về việc Blossom sẽ giảm khả năng di động/cảm ứng, điều đáng báo động là bất cứ ai sẽ cân nhắc việc hỗ trợ di động vào năm 2012. Mọi suy nghĩ về những gì đang xảy ra ở đây và nếu touch/mobile thực sự được hỗ trợ trong tương lai của sproutcore? –

+0

Công cụ hiện đang được xây dựng để biên dịch các ứng dụng hoa chạy trên nền tảng bất kỳ. Rõ ràng, mỗi nền tảng sẽ cần phải được thực hiện riêng lẻ, nhưng tôi nghĩ bạn có thể mong đợi sự hỗ trợ cho các nền tảng chính khá nhanh chóng. Từ những gì tôi đã thấy trong IRC#blossom, những công cụ này sẽ có sẵn vào ngày 1 tháng 4. Thông báo trước là hỗ trợ thời gian chạy sẽ yêu cầu cấp phép. Tôi khuyên bạn nên bỏ qua #blossom trên freenode và bắt đầu đặt câu hỏi. Hoặc nhấn sproutcore google group – hvgotcodes

Các vấn đề liên quan