Tôi có nên sử dụng haml hoặc erb hoặc erubis cho trang web có lưu lượng truy cập tiềm năng cao không?

Question

Gần đây, tôi đã chơi với Haml và thực sự thích cách mã kết quả hiển thị với tôi ... nhà phát triển. Tôi cũng không quá lo lắng về một nhà thiết kế có thể tiêu thụ hoặc thay đổi nó ... chúng tôi là một nhóm nhỏ.

Điều đó nói rằng, bắt đầu công việc trên một dự án mà chúng tôi tin rằng sẽ tạo ra một chút lưu lượng truy cập (ai không?). Tôi lo ngại rằng có những điều tôi không biết về haml. Có bất cứ điều gì erb có thể làm điều đó haml không thể? Haml có tác động tiêu cực khi dự án phát triển không? Có những thứ khác cần được cân nhắc không?

Và cuối cùng ... Haml so sánh nhanh như thế nào với erubis? Tôi thấy rằng nó được cho là đã đánh bại erb và eruby bây giờ ...

Cảm ơn!

Answer 1

Cá nhân tôi sẽ giới thiệu cho chúng tôi erubis trong các mẫu được biên dịch trước.

Đặc biệt nếu không cần tạo khuôn mẫu động. Sau đó, sự suy giảm lớn nhất của bạn sẽ bị giới hạn bởi tốc độ mà ruby ​​có thể phân tích ruby.

Tôi có thể thiết lập một công việc cron nhỏ chỉ giám sát các mẫu nguồn đã thay đổi và tự động biên dịch chúng khi thay đổi mà bạn có thể tắt khi không sử dụng.

Biên dịch một lần, sử dụng nhiều.

Oh, và nếu bạn thực sự lo ngại về tốc độ, Tenjin thể được giá trị một cái nhìn quá (giống người sáng tạo như erubis)

http://www.kuwata-lab.com/tenjin/rbtenjin-examples.html

Answer 2

Tôi nghĩ rằng nó hoàn toàn là vấn đề sở thích cá nhân và bảo trì. Đối với tôi, Haml làm cho các mẫu dễ đọc và dễ hiểu hơn, và hiệu suất là rất chấp nhận được. Cuối cùng, ngôn ngữ tạo khuôn mẫu dường như không phải là nơi bạn cần tối ưu hóa - nhiều khả năng truy vấn cơ sở dữ liệu, chế độ xem hoặc bộ nhớ đệm đối tượng, v.v.

Tuy nhiên, trong trường hợp mẫu ERb, bạn sẽ nhận được hiệu suất tốt hơn về cơ bản miễn phí nếu bạn sử dụng erubis.

Answer 3

Nếu bạn sử dụng Rails, sự khác biệt hiệu suất giữa Haml và erubis là không đáng kể: các mẫu được biên dịch và lưu trữ sau lần truy cập đầu tiên. Kết hợp điều này với phân đoạn và bộ đệm trang và bạn có thể yên tâm rằng lượt xem không phải là nút cổ chai hiệu suất của ứng dụng của bạn.

Câu hỏi bạn nên tự hỏi là: bạn có thích viết Haml không? Nó có giúp bạn làm việc hiệu quả hơn không? Sau đó, bạn có thể quyết định dễ dàng hơn.

Answer 4

Đá cuội. Tôi đã không nhìn thấy bất kỳ số hiệu suất gần đây nhưng nó là khá gần với erb những ngày này. Tôi nghĩ rằng nó có thể nhanh hơn erb nếu bạn bật chế độ xấu xí (ngăn cản sự thụt đầu dòng) Chúng tôi đang làm 2,8 triệu lượt xem trang mỗi ngày với Haml.

Có một benchmarker kiểm tra vào cây nguồn Haml: http://github.com/nex3/haml/tree/master/test

Cập nhật tháng 11 năm 2009

Nathan (nhà phát triển chính Haml của) published some Haml 2.2 benchmarks trên blog của mình.Bạn có thể thấy những con số chính xác ở đó nhưng trong ngắn hạn:

• Bình thường (in đẹp) mode = chậm hơn so với ERB 2,8 lần
• Ugly chế độ (không có các tab khá thêm) = bằng ERB

Bạn có thể bật chế độ xấu xí bằng cách đặt Haml::Template::options[:ugly] = true trong tệp khởi tạo hoặc môi trường. Lưu ý rằng chế độ xấu xí không thực sự xấu xí - kết quả HTML thực sự đẹp hơn nhiều so với ERB - nó không bị thụt lề một cách độc đáo.

Answer 5

Vâng, hiệu suất của Haml tiếp tục cải thiện với mỗi bản phát hành. Ở địa điểm có thể chấp nhận tại thời điểm hiện tại? Đó là để bạn quyết định (tôi có khuynh hướng nói "Có", nhưng đó là lựa chọn của bạn dựa trên nhu cầu của bạn). Nếu bạn thích các mẫu và khả năng đọc mà chúng cung cấp, thì hiệu suất giảm (tuy nhiên không đáng kể) thực sự phải là yếu tố cuối cùng trong quyết định của bạn.

Một trong những công cụ khác mà bạn nên cân nhắc khi sử dụng kết hợp với Haml là make_resourceful, một gem khác của người duy trì Haml (Nathan Weizenbaum) đơn giản hóa rất nhiều thứ RESTful trong ứng dụng Rails.

Nếu bạn có thêm bất kỳ câu hỏi cụ thể nào khác về Haml (và m_r), tôi chắc chắn Nathan sẽ rất vui khi trả lời chúng. Ông có thể đạt được thông qua Jabber/XMPP và email. Thông tin liên hệ của anh ấy có thể được tìm thấy here.

Answer 6

Nếu bạn thích haml hoạt động như thế nào từ quan điểm mã hóa, đừng lo lắng về hiệu suất của công cụ tạo khuôn mẫu quá nhiều. (Mặc dù, như bạn đã chỉ ra, nó bây giờ là nhanh.) Nó chắc chắn có thể tạo ra bất kỳ đầu ra các công cụ khác có thể.

Nói chung, bạn sẽ tiết kiệm năng lượng để thiết lập bộ nhớ đệm hơn là lo lắng về công cụ tạo khuôn mẫu nơi bạn gặp sự cố về hiệu suất.

Answer 7

Tôi yêu HAML vì đây là một công cụ tốt để viết HTML có cấu trúc dễ dàng, và nói chung nó chỉ là một niềm vui để sử dụng. Nhưng nó có rất ít việc phải làm với việc chọn một công cụ dựa trên số lượng lưu lượng truy cập mà một trang web có thể có.

Nếu bạn lo lắng về lưu lượng truy cập, bạn nên lo lắng về việc sử dụng bộ nhớ đệm đúng cách. Và sau đó bạn cần áp dụng các nguyên tắc về hiệu suất ứng dụng web nói chung - kết quả là bạn sẽ có các phản hồi siêu linh hoạt đối với tải trang. Đó là những gì một trang web lưu lượng truy cập cao thực sự cần.

Một vài bài thuyết trình cho thấy làm thế nào để cải thiện hiệu suất trang web có thể được tìm thấy ở đây:

• Michael Koziarski speaks about Rails Performance on 2008 Paris on Rails

• Jeremy Kemper talks about Performance on Rails on RailsConf EU'08

Và là nơi tốt nhất mà tôi biết để tìm hiểu cách sử dụng bộ nhớ đệm đường ray đúng cách là:

• Rails Caching PeepCode screencast