הטרנדים החמים בתחום הווב והמובייל (חלק ג')

סקירה קצרה על המגמות החמות בפיתוח Web ובעיקר בפיתוח Web ל-Mobile. חלק שלישי ואחרון בסדרה

תמונה: יח"צ, עיבוד תמונה

זהו הפוסט השלישי והאחרון בסדרת “הטרנדים החמים בתחום הווב והמובייל” (לחלק הראשון) (לחלק השני).

CSS Meta-Languages

אתם בוודאי מכירים את “שפת” CSS – שפת עיצוב ה-StyleSheets של האינטרנט. מצד אחד, CSS היא שפה רבת יכולות גרפיות, אך מצד שני קשה לקרוא לה “שפה”. CSS היא שפה דקלרטיבית (כלומר: המתכנת מציין את התוצאה הרצויה – לא את הדרך להגיע אליה), והיכולות ה”תכנותיות” (אימפרטיביות) שלה – אינן עומדות בקו אחד עם שפות תכנות בסיסיות… משנות השישים של המאה הקודמת.

לדוגמה: ב-CSS3, הוצגה לראשונה פונקציה חישובית שמאפשרת לבצע חישובים אריתמטיים. במקום שהמתכנת יפתח מחשבון, יקיש ערכים, יחשב ויקליד את התוצאה בתוך קובץ ה-CSS – יהיה ניתן להקליד את החישוב בתוך פונקציית Calc ו”שפת” ה-CSS תחשב אותו. אני לא מדבר על הכפלת מטריצות לוגרתימיות, אני מדבר על פעולה פשוטה כמו 8px+2px+4px.

בעת כתיבת פוסט זה, רק שני דפדפנים נפוצים (מתוך 7, אם נחשיב מכשירי מובייל) תומכים ביכולת החישוב של CSS3. עבור כל שאר הדפדפנים יש לבצע חישוב בראש ולהקליד את התוצאה לתוך ה-CSS.

“מה כל-כך רע בלבצע חישוב קטן בראש?” – אתם עשויים לשאול. “תפעיל קצת את התאים האפורים שלך!”.

ובכן – אני מדמיין את קובץ ה-CSS, חלק אינטגרלי מאתר או אפליקציה, שמכיל את הערך:

width: 531px;

…531 פיקסלים. איך לעזאזל הגעתי ל 531 פיקסלים?!

האם זה 600 פחות X, Y ו Z כפול 2?

האם 551 פיקסלים, שני אלמנטים למעלה, צריכים גם הם להשתנות אם יום אחד אחליט להרחיב את “531 הפיקסלים”? מה עוד צריך להשתנות ולמה?

דחף ראשוני של מתכנת טוב הוא להוסיף הערה:

width: 531px; // box is 560px wide – 2*padding (10px) – icon width (9px)

זה באמת יותר ברור.

יותר ברור – נכון, אבל האם אתם מדמיינים קובץ CSS עם מאות שורות בהערות, שניתן לתחזוקה?

אני שומע בראשי את Uncle Bob זועק בסרטוני הווידאו שלו “!!Comment is a Failure” – “אם כתבת הערה, סימן שנכשלת, לכתוב קוד ברור מספיק על מנת שיחיה בפני עצמו” (הרמת הקול היא במקור).

כתבתי מספיק הערות במשך חיי שיצאו (דיי מהר) מסנכרון עם הקוד ונותרו חסרות פשר, על מנת לדעת שהוא צודק. האם תהיה ישועה או האם תכנות ווב תמיד ירגיש “חאפרי”, מול תכנות צד-שרת?

Sass

הלוגו של Sass: קיצור של Syntactically Awesome Stylesheets. הספרייה יועדה למעצבים - ולכן השיווק שמתאים יותר לפלח שוק זה. מקור: http://sass-lang.com/

היו כמה ניסיונות להתמודד עם הבעיה בעזרת jQuery (או ספריות דומות): במקום לשכפל קוד לא קריא בקובץ CSS – העבירו חלק נכבד מ”קוד” העיצוב ל-jQuery (שיכולות ה-Selection שלו מקבילות כמעט ל-CSS). קוד jQuery נטען בעליה והחיל סגנונות עיצוב על גבי ה-HTML. באופן זה ניתן להשתמש ב-JavaScript שמספק יכולות מתקדמות למדי לשימוש חוזר בקוד.

הגישה היא נחמדה – עבור המפתח, אך יש מעט מאוד מעצבים גרפיים שיסכימו להתעסק עם קובצי JavaScript עבור משימת העיצוב. כמו כן יש השלכת ביצועים לא קטנה: jQuery צריך לטייל על ה-DOM בזמן ריצה – פעולה יקרה למדי.

בשנת 2007 שוחררה ספרייה חדשנית שהתהדרה בססמאות אלגנטיות. קראו לה Sass [א].

Sass היא שפה חדשה שמאפשרת לכתוב StyleSheet אלגנטיים שקלים לתחזוקה. מכיוון ששום דפדפן באותו הזמן לא תמך בקובצי Sass (מצב זה לא השתנה מאז) – הפרויקט כלל גם קומפיילר שהופך את קבצי ה Sass לקובצי CSS מוכרים.

מי שיתבונן בקובצי ה-Sass יזהה אלמנטים מוכרים משפת רובי, ואכן משם ההשראה. מתכנתי Ruby on Rails הם אלו שהמציאו את Sass. באתר הבית של Sass תוכלו למצוא דוגמאות למכביר כיצד Sass הופכת את כתיבת ה-StyleSheets למלאכה פשוטה ומהנה יותר. הנה כמה דוגמאות:

קבועים (נקראים בטעות “משתנים”) אשר מאפשרים לקבוע ערך פעם אחת ולהשתמש בו הרבה פעמים. שינוי עתידי ידרוש שינוי במקום אחד בלבד: הגדרת הקבוע.

Mixins (מקבילות דקלרטיביות לפונקציות) – היכולת להגדיר פעם אחת מספר שורות שחוזרת על עצמן ולהשתמש בהן שוב ושוב. שימוש נפוץ הוא “לעטוף” בפקודה אחת את הצורות השונות בהן קוראים לפקודה בדפדפנים שונים, כך שהקוד יציג רק את הפעולה הרצויה מבלי לשכפל את התחביר של הדפדפנים השונים. rounded-corners או gradient הן דוגמאות טובות.

הנה דוגמה איך נראה Mixin בפועל:

.gradient(@color, @start, @stop) {
background: @color;
background: -webkit-gradient(linear,left bottom, left top,color-stop(0, @start), color-stop(1, @stop));
background: -ms-linear-gradient(bottom, @start, @stop);
background: -moz-linear-gradient(center bottom, @start 0%, @stop 100%);
}

בהמשך, אוכל פשוט לקרוא ל:

.gradient(#F5F5F5, #EEE, #FFF);

על מנת להחיל גרדיאנט שתומך ב-3 דפדפנים (כל אחד עם תחביר מעט שונה) או רקע קבוע אם גרדיאנט לא נתמך.

Sass מציגה עוד יכולות חשובות, כגון nesting (היכולת לסדר את הקובץ ע”פ מבנה ה-markup ולצמצם התנגשויות אפשריות ב-CSS), חלוקת הקוד לקבצים מבלי לגרוע בביצועים, פונקציות חישוביות, לוגיות או ניהול צבעים. פונקצית ()opacify, למשל, מאפשרת לכם להוסיף שקיפות לצבע מבלי לפרק אותו לערוצי ה RGB, כפי שנדרש בפונציה הסטדנדרטית של CSS – הרי היא rgba.

על גבי Sass קיימת ספריה עשירה של mixin בשם Compass שמציעה סט יכולות מגוון ובוגר. את הכל יכולתם לכתוב בעצמכם – אך ה-mixins של Compass כבר עברו שיפורים רבים.

שפת Meta-CSS נוספת, דומה להפליא ל-Sass, נקראת LESS – לא אתפלא לגלות שהיא Fork של Sass בימים מוקדמים יותר. הצעד הגדול ביותר שלה היה להחליף את הקומפיילר של Ruby בו משתמשת Sass בקומפיילר שנכתב ב-JavaScript. ישנן עוד כמה שוניות פחות משמעותיות.

השפה האחרונה שאזכיר, פופולארית פחות מהשתיים שהוזכרו לעיל – אך עדיין נפוצה, היא ספרייה בשם Stylus. היא כבר עברה לתחביר נקי מכל תו מיותר (הושפעה מ-Haml. כך גם התחילה Sass – אך היא החליטה לחזור לתחביר דומה יותר ל-CSS). אני אישית מוצא את התחביר שלה יותר מדי “hardcore” מכדי להציג אותו בפני מעצבים גרפיים.

JavaScript Meta-Languages

הרשו לי לחסוך לכם קריאה מיותרת: אותו התהליך שהתרחש עבור CSS – קרה בערך במקביל גם בשפת JavaScript. שפות “מטא” שאינן תואמות ל-JavaScript עצמה, אך מציגות שיפורים שונים, ומתקמפלות בסופו של דבר לקוד JavaScript סטנדרטי.

השפה הנפוצה בתחום היא ללא ספק CoffeeScript, תחת הסלוגן “Expose the good parts of JavaScript”.

בניגוד ל-Sass ו-LESS שבאות להתמודד עם חוסר-יכולת-ביטוי של שפת ה-CSS, שפת JavaScript עשירה למדי ומלאה ב”שטיקים” המאפשרים גמישות רבה למתכנת. שפות המטא של JavaScript באו דווקא לעשות את ההפיך: להגביל את JavaScript ולהגן על המתכנת בפני שורה של Pitfalls אפשריים.

בנוסף – הן מציגות תחביר משופר, יותר תמציתי ואלגנטי. אלמנטים רבים שחוזרים על עצמם ב-JavaScript לא באמת נדרשים והסרתם – יכולה לשפר משמעותית את קריאות הקוד.

לדוגמה, במקום לכתוב:

var Animal, Horse, Snake, sam, tom,
__hasProp = {}.hasOwnProperty,
__extends = function(child, parent) {
for (var key in parent) {
if (__hasProp.call(parent, key)) child[key] = parent[key];
} function ctor() { this.constructor = child;
} ctor.prototype = parent.prototype; child.prototype = new ctor; child.__super__ = parent.prototype; return child; }; Animal = (function() { Animal.name = ‘Animal’; function Animal(name) {
this.name = name;
} Animal.prototype.move = function(meters) {
return alert(this.name + (” moved ” + meters + “m.”));
};

return Animal;

})();

Horse = (function(_super) {

__extends(Horse, _super);

Horse.name = ‘Horse’;

function Horse() {
return Horse.__super__.constructor.apply(this, arguments);
}

Horse.prototype.move = function() {
alert(“Galloping…”);
return Horse.__super__.move.call(this, 45);
};

return Horse;

})(Animal);

אפשר לכתוב בקופיסקריפט:

class Animal
constructor: (@name) -> move: (meters) ->
alert @name + ” moved #{meters}m.” class Horse extends Animal
move: ->
alert “Galloping…”
super 45

בד”כ חיסכון הקוד לא יהיה כ”כ גדול, אך בכל-זאת החלטתי להביא דוגמה זו כדי להראות את הפוטנציאל.
ניתן לזהות בתחביר של CoffeScript אלמנטים רבים משפת רובי וגם מפייטון (כלומר, גישת פייטון שהועדפה על גבי רובי).

ובכן, מה החסרונות של קופיסקריפט?

יש ללמוד שפה חדשה, לעבור עוד שלב של קומפילציה ולהסתפק בסט כלים חיצוניים קטן יותר (למרות שיש כבר לא מעט IDEs בעלי תמיכה כזו או אחרת לקופיסקריפט).עוד ביקורת אפשרית הוא שאולי, אבל אולי, קופיסקריפט לא הולכת רחוק מספיק: קופיסקריפט משפרת את התחביר, מונעת טעויות ג’אווהסקריפט נפוצות (למשל הגדרה של משתנה ללא “var” – כך שהוא הופך להיות גלובלי או שימוש ב”==” ולא ב “===”) אך היא עדיין לא מאפשרת קפיצת מדרגה ביכולת ה static checking של השפה. כמתכנת צד-שרת עדיין חסרה לי היכולת להגדיר משתנה שיספק לי Type Safety או בכלל לתפוס עוד טעויות בעזרת הקומפיילר.

שפה אחרת, עם מאפיינים דומים לקופיסקריפט, שכן עושה צעד נוסף בכיוון זה היא Dart של גוגל. יעד מרכזי של השפה הוא לאפשר לקוד להתחיל לרוץ גם לפני שכל הקוד נטען – וכך לספק פידבק מוקדם למשתמש. זמן טעינה ארוך ללא תגובה היא בעיה ידועה של אפליקציות גדולות בג’אווהסקריפט.

דפדפן כרום [ג] יודע להריץ את Dart ללא קומפילציה ל JavaScript וכך להשיג ביצועים אפילו גבוהים יותר. כרגע לא נראה שדפדפנים אחרים ימשיכו בקו זה.

class Point {
num x, y;
Point(num this.x, num this.y);
Point scale(num factor) => new Point(x*factor, y*factor);
num distance() => Math.sqrt(x*x + y*y);
} void main() {
Point a = new Point(2,3).scale(10);
print(a.distance());
}

הנה דוגמה לשפת DART: תחביר קרוב יותר ל C-Syntax שנהוג בג’אווהסקריפט אך עדיין עם קיצורים רבים. “num” הוא תחליף ל-“var” שיספק לי גם בדיקה בזמן קומפילציה.

בניגוד לשאר הטכנולוגיות שהצגתי בסדרת פוסטים זו, דארט עדיין לא הוכיחה את עצמה. האמת שהיא אפילו חדשה למדי וגרסה רשמית שלה שוחררה רק לפני חודש.

מפתח ווב ותיק ציין בפני השגה מעניינת: “לגוגל יש היסטוריה של טכנולוגיות מרשימות, שלבסוף לא תופסות”, הוא אמר. לא אנסה לנתח את הסיבה – אך זו בהחלט נקודה שאני מזדהה איתה וששווה התייחסות לפני שאתם קופצים וממירים את כל הקוד שלכם ל-DART.

Generators

תהיתם פעם איך מפתחי ווב מנוסים מייצרים חלקים מורכבים ב-CSS שלהם?

למשל, אתם רוצים לייצר גרדיאנט מושקע שכזה:

בתוכנות גרפיות יש פקדים קלים על מנת לייצר אותו. איך אתם מעבירים אותו ל-CSS?

כמה שניות בראש יקחו לכם לתרגם אותו לקוד, הברור מאליו, הבא:

background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,rgba(180,221,180,1)), color-stop(17%,rgba(131,199,131,1)), color-stop(33%,rgba(82,177,82,1)), color-stop(67%,rgba(0,138,0,1)), color-stop(83%,rgba(0,87,0,1)), color-stop(100%,rgba(0,36,0,1)));

כמובן שזה רק דפדפן ואחד ויש בערך 6 צורות מעט שונות להגדיר את אותו הגרדיאנט לדפדפנים שונים.

אם אינכם משתייכים ל”גאונים המתמטיים” שמחשבים ערכים כאלו בראש, אבל כן משתייכים ל”עצלנים” שמחפשים דרכי קיצור – יש הרבה כאלו באינטרנט. אמנם אין הרבה IDEs חזקים לפיתוח ווב אך יש הרבה מאוד כלים (Generators) שייצרו לכם snippets של CSS או JavaScript שיכולים לחסוך לכם הרבה עבודה.

colorzilla gradient-editor הוא הכלי שייצר את קוד הגרדיאנט למעלה וישמח לייצר קוד שמתאים לכל הדפדפנים.
CSS Layout Generator יסייע לייצר Layouting בעזרת CSS בלבד – פעולה שעשויה להיות מלאכת מחשבת
השם עשוי להפתיע אתכם, אך CSS Button Generator ייצר כפתורים עגולים ויפים בעזרת CSS בלבד.
kuler יספק לכם sets של 5 צבעים שמתאימים אחד לשני. לא עוד אתר בעיצוב גיאורגי (החליפו את המחוק בכל שם שנותן לכם קונוטציה לעיצוב גרוע).
Pattern Cooler ייצר לכם תמונות רקע ש”מתחברות אחת לשנייה” ויוצרות טאפט.

חפשו בגוגל “Generators” ותראו שהאינטרנט מלא בכלים קטנים שמסייעים למפתחי ווב.

ולסיום – IDE מתקדם לפיתוח ווב

כלי פיתוח לווב, משום מה, תמיד היו מאותגרים. לרוב הם לא סיפקו הרבה יותר מ-Syntax Highlighting ו-Auto-Completion בסיסי מבוסס השפה. IDE מתוחכם יחסית ששינה את התמונה הוא Aptana והוא מסופק בחינם. עד לא מזמן, הוא כנראה היה ה-IDE המתקדם ביותר לפיתוח Web.Aptana הוא מורכב ומסורבל ופשוט לא מסודר נוח. מעולם לא חיבבתי אותו. העדפתי אפילו להשתמש ב++Notepad שהיה מוגבל אך זריז. עד שגיליתי את מה שמפתחי הווב המתוחכמים מכירים: IDE מבית IntelliJ בשם WebStorm.

כמובן שיש פה עניין של טעם אישי, אך אם אתם מפתחים ווב בחצי משרה או יותר, ומוכנים להשקיע bare 100$ בשביל איכות החיים שלכם – כדאי לכם להוריד גרסת ניסיון של Web Storm. אני לא אפרט את רשימת הפ’יצרים (תמיכה ב SASS, LESS, CoffeeScript, Node.js השלמה אוטומטית חכמה, Refactoring ו Debugger חזק – אופס, פירטתי). הדבר שאני הכי אוהב ב IDE הזה שהוא מרגיש לי טבעי ו”זורם איתי” בוייב הנכון. לא מקשה עלי, כמו Aptana. שלא תאמרו שלא ידעתם.

[א] לא לבלבל עם SaaS – Software as a Service
/
[ב] ההדמיה היא מוצלחת – אך בהחלט ניתן לראות שאלו הם “תרגילים” וכי תחביר השפה לא מספק כלים מיוחדים לסייע לתאר מקרים נפוצים אלו.
/
[ג] בעצם V8.

הפוסט פורסם לראשונה בבלוג ארכיטקטורת תוכנה.

ליאור בר-און

ליאור בר-און הוא Chief Architect בחברת סטארטאפ ישראלית גדולה.

הגב

4 תגובות על "הטרנדים החמים בתחום הווב והמובייל (חלק ג’)"

התחבר עם:

Photo and Image Files

Audio and Video Files

Other File Types

* היי, אנחנו אוהבים תגובות!
תיקונים, תגובות קוטלות וכמובן תגובות מפרגנות - בכיף.
חופש הביטוי הוא ערך עליון, אבל לא נוכל להשלים עם תגובות שכוללות הסתה, הוצאת דיבה, תגובות שכוללות מידע המפר את תנאי השימוש של Geektime, תגובות שחורגות מהטעם הטוב ותגובות שהן בניגוד לדין. תגובות כאלו יימחקו מייד.

סידור לפי: חדש | ישן | הכי מדורגים