هل يستحق تعلم هامل وساس؟

Question

في تجربتك المهنية هامل & ساس ثبت أنه مفيد؟ في أي طريق؟

Answer 1

هامل لطيف ، وأنا أستخدمه كثيرًا ، لكن ساس يستحق ذلك بمفرده ، خاصة إذا كان عليك بناء أوراق أنماط معقدة. على سبيل المثال ، أحد أسوأ الأشياء حول CSS هو مقدار التكرار الذي يجب عليك فعله عند تسمية المختارين. في CSS ، عليك أن تفعل

#navbar ul 
#navbar ul li a
#navbar ul li a:hover

مع Sass ، يمكنك ببساطة عش هؤلاء المهملات بشكل طبيعي.

#navbar

  ul
    margin: 0
    padding: 0
    list-style: none
    width: 100%

    li
      margin: 0
      float: left
      margin-right: 10px
      border: 1px solid #000

      a
        text-decoration: none

        &:hover
          color: red

يمكنك أيضًا استخدام المتغيرات

!border_color = #333

.box
  border = 1px "solid" !border_color

ويمكنك استخدام الرياضيات معهم

!measure = 18px
!text_size = !measure / 1.5

body
  font-size = !text_size
  line-height = !measure

h1
  font-size = !measure
  margin-bottom = !measure

h2
  font-size = !measure + 2

#wrapper
  width = !measure * 50

يمكنك أيضًا مشاركة الرمز

=rounded
  -moz-border-radius: 4px
  -webkit-border-radius: 4px
  border-radius: 4px
  border: 1px solid #000

.box
 +rounded

هناك الكثير من القوة في هذا لدرجة أنك مدين بها لنفسك لتعلمها. بالإضافة إلى ذلك ، فإن النتيجة النهائية هي CSS العادية بحيث يمكن تحويلها.

لا تنسى CSS2SASS الذي يحول CSS الحالية إلى ملفات SASS!

يمكنك اللعب مع بعض الأمثلة في http://rendera.heroku.com/ إذا احببت. إنه موقع قمت ببنيه لمساعدة الناس على تعلم HTML5 و CSS3 ولدي دعم لكل من Haml و Sass هناك.

أيضًا ، ألقِ نظرة على staticmatic (staticmatic.rubyforge.org) للحصول على طريقة رائعة للقيام بموقع ويب ثابت مع Haml و Sass. يقوم بإنشاء مواقع ويب يمكنك تحميلها على المضيفات الثابتة ولديها نظام تخطيط وقالب مشابه لروبي على القضبان.

لمعالجة السؤال المباشر الذي طرحته ، عن طريق "هل يستحق كل هذا العناء" ، الإجابة هي نعم. إن القدرة على استخدام المتغيرات ، وتجميع الأشياء بسهولة من قبل المحدد ، ومشاركة التعليمات البرمجية عبر الوحدات النمطية تجعل أوراق الأنماط المعقدة أسهل بكثير. لا يستغرق بناء أوراق الأنماط وقتًا طويلاً على الإطلاق ، ويمكنك استخدام إطار Compass الممتاز للمضي قدمًا. على سبيل المثال ، يمكنك استخدام وحدات 960.gs أو Blueprint لخلط هذه الأطر في أوراق الأنماط الحالية. وبهذه الطريقة ، ليس عليك تغيير علامة الرمز الخاص بك. قد لا يكون إضافة 960.gs و "GRID_12" و "Container_12" إلى كل علاماتك الممكنة ، ولكن مع Compass و Sass ، إنه نسيم.

يسهل Sass أيضًا الحصول على أوراق أنماط متعددة لوضع التطوير وإنشاء ورقة أنماط واحدة للإنتاج ، وبالتالي تحسين الأداء من جانب العميل (مكالمات أقل إلى الخادم في تحميل الصفحة.)

هامل لها فوائدها الخاصة ، على الرغم من أنها ليست ملحوظة مثل ساس. Haml يجعل من السهل بشكل لا يصدق أن تعشص عناصر وإعلان divs ... باستخدام حتى 960.gs العادية على سبيل المثال ، من السهل مع Haml:

#header.container_12
  .grid_12
     %h1 Welcome!
#middle.container_12
  .grid_8
     %h2 Main content
  .grid_4
     %h3 Sidebar

كتابة أقل بكثير. وإذا قررت أنك بحاجة إلى إضافة غلاف حول كل ذلك لسبب ما ، فما عليك سوى المسافة البادئة للشيء تحت علامة جديدة.

امل ان يساعد. أنا <3 ساس.

Answer 2

يحتوي موقع الويب الخاص بي الحالي على أكثر من 800 ملف Haml و 150 ملف Sass ، واسمحوا لي أن أخبرك أنه ساعد في تطوري بشكل كبير.

أكبر نعمة هي من حيث التطور السريع: يتطلب إنشاء ملفات Haml/Sass كتابة أقل بكثير ، بحيث يمكنك التخلص من منطق العرض التقديمي الخاص بك مع ضغطات مفاتيح أقل بكثير مما لو كنت تفعل قالب ERB.

أجد أيضًا ملفات HAML أسهل بكثير للقراءة ، وأقل عرضة للخطأ.

YMMV ، لكنني وصلت إلى النقطة التي لا يبدو أن استخدام هامل وكأنه عمل روتيني.

Answer 3

TL ؛ DR - على الرغم من شعبيته ، فأنا أفضل عدم استخدام Haml أو Sass ، لكني أحب SCSS.

يبدو أن الإجماع العام على هامل يؤيده بأغلبية ساحقة ، لكنني شخصياً لا أهتم به.

إذا كان نيتي هو إنشاء HTML ، فأنا أفضل أن تكون لغة القالب هي في أقرب وقت ممكن. هذا يتجنب الاضطرار إلى تعلم طبقة أخرى من عدم التوجيه تضيف فرصة للارتباك والخطأ وكذلك تكبد النفقات العامة المعرفية.

أجد القيود التي يضعها هامل في استخدامها المفضل للمسافة البيضاء لقابلية القراءة والغلاف الخطير لتكون مرهقة وغالبًا ما تؤدي إلى بناء جملة يصعب قراءتها.

واجهت مؤخرًا خطأً خفيًا في قالب Haml الذي كان من الواضح على الفور إذا كان القالب ERB ، على سبيل المثال:

 .table
   .thead
   .tr
   .tr

صفوف الجدول ليس ضمن علامة THEAD ، وهي هامل صالحة تمامًا ، ولكنها غير صحيحة فيما يتعلق بهيكل HTML المقصود. بينما ظهرت الصفحة بشكل صحيح ، فشل محدد CSS ، مما أدى إلى فشل صامت لبعض رمز JavaScript.

أنا متأكد من أن هذا النوع من الأخطاء سيكون واضحًا لمعظم مستخدمي Haml ، كما هو موضح في عزلة ، ولكن في سياق قالب أكبر ، قد يكون من الصعب اكتشافها ؛ خاصة لمطور جديد على هامل.

من ناحية أخرى ، إذا كان هذا ERB أو HTML:

 <table>
   <thead>
   <tr>...</tr>
   <tr>...</tr>

بالنسبة إلى عيني ، يكون الخطأ في الهيكل أسهل بكثير بسبب الطريقة التي يتم بها وضع مسافة بادئة تقريبًا ERB و HTML.

بعد أن أمضيت عقدين من الزمن في كتابة HTML ، يجب أن أعترف أن لدي فخرًا معينًا في كتابة HTML المتشكل جيدًا ولا أرى أي سبب لتعلم طريقة مختلفة لتمثيلها وتعلم جميع الأنماط المرئية الجديدة اللازمة لاكتشاف الأخطاء.

من ناحية أخرى ، أحب كثيرًا SCSS (على عكس SASS) لأن SCSS هي في الأساس مجموعة من CSS. لا يضيف طبقة جديدة تمامًا من عدم التوجيه أحتاج إلى ترجمة عقلياً. إنه يضيف فقط تغييرًا متواضعًا في بناء الجملة الذي يوفر تمثيلًا أكثر إيجازًا (وجافًا) لـ CSS الذي أجده من السهل جدًا قراءته وفهمه.

في الواقع ، أنا أفضل عدم استخدام أي لغة تفرض بناء جملة صارمة فيما يتعلق بكيفية قيامني بمسافة بادئة أو لف كودتي مثل Python. أو اللغات التي تعمل فقط كطبقة غير توجيهية أعلى لغة أساسية مثل Coffescript.

أنا لا أقول إنني أعتقد أن التجريد والانحراف سيئان في لغات البرمجة ؛ أنا فقط أفضل عدم استخدامها فيما يتعلق باللغات المحددة التي تمت مناقشتها هنا.