מקודד לשוא|וידויים של מוח מקוון

עד עכשיו התעסקתי בהעברת המידע ללקוח בלי להתחשב בעומסי השרת אך מה קורה שכמות המידע מתחילה להיות ממש גדולה וכבר עוברת את גבולות המכונה ? איך מצליחים למצוא את המידע המתאים מהמכונה המתאימה בזמן סביר ?

Sharding (בתרגום מילולי שבירה לרסיסים) היא שיטה של חלוקת אופקית במאגר מידע או מנוע חיפוש.

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

במה שונה גישת החלוקה מגישות קימות ?

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

בעקבות המחקר והעבודה של סונדרס וצוותו הוציאו יאהו כלי בדיקות בשם YSLOW כתוסף דפדפן של פיירפוקס. מאז סונדרס עבר לגוגל וגם הם הוציאו כלי דומה בשם PAGE SPEED במהלך שמזכיר קצת את מיקרוסופט (ולא החלקים הטובים שלה)

בהתאם לממצאים של סונדרס וצוותו גובשו הכללים הבאים:

1. צמצום כמות קריאות HTTP ,זאת על ידי שימוש בטכניקות כמו CSS SPRITES ואיחוד קבצי CSS ו JS .

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

3. שימוש נכון בתאריך תפוגה (expiration header) לכל משאב (לא רק לתמונות), במחקר שערכו גילו כי באתרים שונים הרבה משאבים קבועים (עד כ 70%) יכולים להיות עם תאריך תפוגה ארוך יותר. מעבר לתאריכי תפוגה ארוכים מחייב התייחסות ארכיטקטונית לעדכון גרסת משאב מסוים. לדוגמה – תיקון בקוד האתר דורש שינוי קוד ג'אוה סקריפט, מכיוון שאנו השתמשנו בתאריכי תפוגה ארוכים התיקון אף פעם (או עוד הרבה מאוד זמן) יגיע ללקוחות ותיקים הפתרון הוא חתימת גרסאות בשם הקובץ או כתובתו (URL)

4. שימוש ב GZIP (נכתב כחלק מפרוטוקול HTTP) נתמך ברוב הדפדפנים וחוסך כ 70% מהתעבורה אם משתמשים בו על כל המשאבים הטקסטואליים. בחלק גדול מהמקרים GZIP מופעל רק על קבצי HTML ומזניח שלא לצורך משאבי טקסט אחרים כגון CSS ו JS.

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

6. להעביר את הקישורים לקבציי JS לתחתית העמוד, טעינת קובץ ג'אוה סקריפט חוסמת כל הורדה אחרת (בכל מצב אחר הדפדפן מבצע הורדות מקביליות) וחוסמת את רענון תצוגת המסך.

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

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

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

10. שימוש בכלי ניקוי קוד (minification)  להורדת הערות רווחים וקיצור קוד.

11. הימנעות מ REDIRECT אם בקריאות שרת כגון 301 ו 302 או שימוש בקוד HTML META או על ידי ג'אוה סקירפט ככל מקרה תהיה טעינה כפולה הראשונה של הדף המפנה ורק לאחר מכן כתובת היעד.

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

13. הגדרות ETAGS , תגיות יישות (ETags) הן מנגנון אשר שרתי אינטרנט ודפדפנים משתמשים כדי לקבוע אם רכיב בזיכרון המטמון של הדפדפן תואם אחד בשרת המקור (ישות יכולה להיות תמונות, סקריפטים, CSS, וכו ') .התגיות נוספו לספק מנגנון אימות גמיש יותר מאשר תאריך התפוגה.

14. הכנסת AJAX לזיכרון המטמון, בהרבה מקרים הקריאות הינם פרסונליות והאינסטינקט הראשוני הוא לא לשמור את המידע במטמון. אך למרות שהמידע אישי לא תמיד הוא משתנה לעתים קרובות. מומלץ להשתמש באותה טכניקה שמתוארת בסעיף 3.

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

משך טעינת עמוד

הממצא המשמעותי בעבודתו של סונדרס הוא שהזמן שהעמוד נבנה בצד השרת (כולל הבקשה והחזרה של ה HTML) הוא כ 10% עד 20%. שיפורי ביצועים בשרת הנם הכרחיים לשיפור יחס כמות משתמשים לחומרה, וצריכת חשמל, אך משנים במעט את זמני התגובה של אתר ממוצע. רוב זמן הטעינה עובר על טעינה וניתוח של סקריפטים (CSS \ JS) וטעינה של תמונות ומשאבים אחרים מהרשת.

גישה לזיכרון המטמון

50% מהמשתמשים מגיעים לאתר ללא זיכרון מטמון וכ 20% מכלל הצפיות נעשה עם מנגנון ריק (המחקר נעשה על אתרי YAHOO) , חווית הטעינה הראשונית הנה הרבה יותר נפוצה מהמקובל לחשוב, וצריך לתכנן את האתר בהתאם.

ניתן ללמוד על מחקרים אלו ועוד בהרצאתו.

משפט CAP מתאר מערכת בעלת עם מבנה נתונים או מצב זיכרון (state) העונים על המאפיינים הבאים:

1. עקביות (Consistency) – כל לקוח של המערכת מקבל את אותם נתונים גם אם התבצעו עדכונים במקביל.
2. זמינות (Availability) – המערכת משרתת את כל בקשה של לקוחותיה.
3. סבילות חלוקה (Partition tolarance) – ניתן לפצל את מבנה הנתונים או מצב הזיכרון על פני מספר שרתים, או במילים אחרות לפצל את השירות על פני כמה צמתים ברשת.

הטענה היא שבתכנון ובניית מערכת ניתן לבחור רק שני מאפיינים מהשלושה .

להלן ההוכחה  (מקור ג'וליאן בראון)

התרשים מראה מערכת מחולקת אשר מכילה שני צמתים ברשת , N1 ו N2. שניהם חולקים פיסת מידע V (כמה עותקים לספר במלאי), עם הערך V0. על הצומת N1 רץ אלגוריתם שנקרא A ואנו יוצאים מנקודת הנחה שהוא צפוי, חסר באגים, ומהימן.על הצומת N2 רץ אלגוריתם דומה שנקרא B . בניסוי A כותב ערכים חדשים של V ו-B קורא ערכים של V.

התמונה למעלה מתארת תרחיש רגיל (המערכת עובדת כשורה) ,והפעולות הבאות יקרו:
1. Aכותב ערך חדש ל V (נקרא לו V1)
2. הודעה M עוברת מ N1 ל N2 ומעדכנת את העותק של V
3. כל קריאה של B תחזיר את הערך החדש V1

התמונה הזו מתארת טעות, הודעת העדכון (M) לא עברה. מכאן שבשלב 3 קריאה ל B תחזיר ערך לא עדכני.

קריאה ל A ו B יחזירו תוצאות שונות אני מקווה שכאן הבעיה כבר מובנת, נגדיל את קנה המידה לכמה מאות פעולות וזה הופך לבעיה גדולה. אם M הוא הודעה אסינכרונית אז לN1 אין דרך לדעת אם N2 קיבל את ההודעה. אפילו עם מסירה מובטחת של M , אין ל N1 דרך לדעת אם הודעה מתעכבת או שמשהו כשל בN2. הפיכת M לסינכרונית לא עוזרת כי התייחסות לסנכרון כפעולה אטומית יגרום לעקבת (latency בהעדר תרגום מתאים) וזה מפר את עקרון הזמינות. ההוכחה, באמצעות וריאציה,מראה כי אפילו במודל סינכרוני חלקי לא ניתן להבטיח אטומיות.

אז מה CAP אומר לנו ? שאם אנחנו רוצים ש A ו-B יהיו בעלי זמינות גבוהה (כלומר לעבוד עם עקבת מינימלית) ואנחנו רוצים שהצמתים N1 עד *N (כאשר * יכול להיות מאות או אפילו אלפים) יהיו בעלי סבילות חלוקה (שידעו להתמודד עם אבדון הודעות, הודעות שלא נשלחו, תקלות חומרה ותקלות תוכנה) אז לפעמים אנחנו הולכים לקבל מקרים שבהם הצמתים לא מסונכרנים וצומת אחד חושב כי V הוא V0 (עותק של ספר אחד) וצמתים אחרים יחשבו כי V הוא V1 (לא אותו עותק).

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

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

על פי הנחתי מפוסט קודם מאפיני שירות web 2.0 ישנו שינוי עיקרי מול שירותי "WEB 1.0" והוא כתיבה. בעולם ה WEB 2.0 כל משתתף בשירות יכול ליצור תכנים, פרט "קטן"המשנה את ארכיטקטורת התוכנה בגדול.

מערכות ה WEB 2.0 נאלצות להתמודד עם מבני נתונים עם קשרים מורכבים ותצוגות מידע אישיות למשתמשים. אם ב YNET כל אחד שנכנס רואה את אותו עמוד הבית אז בפייסבוק כל משתמש מקבל עמוד בית "פרטי" ודינאמי , תהליך הקטנת העומסים באמצעות מנגנוני מטמון (cache בהעדר תרגום מתאים) הופכת למסובכת מאוד.

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

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

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

כל זאת ועוד בהמשך

רוב ממשקי ה WEB 2.0 מפותחים כאתרי אינטרנט בטכנולוגיות HTML CSS JavaScript  אשר הינן תקינות של W3C ומהוות סטנדרט תעשייה בפיתוח אפליקציות ושירותים מבוססי דפדפן. ישנם גם ממשקים שמפותחים בטכנולוגיות אחרות, לרוב משום שהטכנולוגיות הסטנדרטיות אינן מספקות פתרון לצרכי האפליקציה.

HTML וטכנולוגיות W3C

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

סט טכנולוגיות W3C

לפתח בסטנדרט לדפדפנים דורש ידע ב 3 טכנולוגיות לקוח עיקריות

• HTML שפת תאגים המיועדת לעימוד אלמנטים בתוך הדפדפן (טקסט , גרפיקה וכו') היא שפה הצהרתית ואין בה מושגים כמו זמן, לולאות ומצב זיכרון משותף.
• JavaScript שפה פרוצדורלית המשומשת לבניית מנועי התצוגה ותקשורת.
• CSS שפה הצהרתית שמשמשת לעיצוב וסגנון התוכן.

עמוד HTML בן ימנו בדרך כלל מורכב מסך הטכנולוגיות האלה .

סטנדרטי W3C נתמכים על ידי חברות מובילות בתעשייה . היתרון בטכנולוגיות אלו שהן סטנדרטיות ונפוצות החסרונות – קצב השינויים והתפתחות הטכנולוגיה מאוד אטיים וחוסר בממשקי תוכנה (API) עדכניים.בשנים האחרונות גוגל תומכת ומקדמת מאוד את הסטנדרטים של W3C בניסיון להוציא את תקן HTML5 ניתן לשער כי מהלך זה נובע עקב בנית תשתיות התצוגה בצורה כמעט בלעדית על גבי סט טכנולוגיות זה והשקת הדפדפן כרום.

Adobe Flash/Flex

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

Microsoft Silverlight

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

Oracle Java FX

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

עדכון בתגובה ל @ArialBH "סילברליט לא בשל ?"

לצערי קשה לי להציע את הפלטפורמה ללקוחות בעיקר בגלל הסיבה שהיא לרוב מצריכה התקנה של הפלאג, לעומת פלאש שמותקן ב 90% מהמקרים. הפיצ'ר סט שלהם הוא די דומה, לדוגמה אם לקוח היה צריך להשתמש במאפין ספציפי שלא קיים בפלאש (כמו פיתוח קודקים לוידאו) הייתי ממליץ על הטכנולוגיה אבל ברוב המקרים פלאש נותן יותר וגם יש מאחוריו קהילת מפתחים גדולה מאוד.

בעצם מה שאני מנסה להגיד זה שהבשלות היא גם אימוץ הטכנולוגיה ע"י מפתחים וגולשים.

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

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

איך זה עובד בפועל?

משתמש גולש לשירות.באותה בטעינה ראשונית  יטענו הגרפיקה ומנוע התצוגה (בעצם המשתמש מוריד ומריץ תוכנה שרצה ע"ג הדפדפן) לאחר שהתוכנה נטענת מנוע התצוגה ניגש לשרתי האתר וטוען  מידע בצורה אסינכרונית. עם טעינת המידע המנוע (שרץ על גבי הדפדפן) משתמש ביכולות כתיבת ה DOM על מנת להוסיף תוכן (ולעיתים גם חלקי אפליקציה חדשים) בצורה דינמית ללא רענון העמוד וטעינה מחדש של האפליקציה.

מוצרי WEB 2.0 כוללים בדרך כלל את המאפינים הבאים :

• חיפוש – מציאת המידע באמצעות חיפוש מילות המפתח.
• קישורים – קישור למדריכים ומידע אחר.
• יצירה – היכולת של כל משתתפי השירות לכתוב ולעדכן תוכן בצורה שיתופית להבדיל מהצורה המסורתית של מתן אפשרות ניהול רק לקומץ מנהלי השירות. לדוגמה בויקי, משתמשים רשאי לערוך למחוק ולכתוב מחדש ערכים. בבלוגים, הודעות ותגובות של אנשים נבנות לאורך זמן , ובאתרים חברתיים התוכן הוא זרם מידע שנבה מפעילות החברים בשירות.
• תגיות קיטלוג של תוכן על ידי המשתמשים על ידי הוספת מילות מפתח המתארות את התוכן ללא תלות מראש בקטגוריות מובנות .
• הרחבות הפיכת השירות לפלטפורמה תכנותית מעבר למערכת הצגת תוכן .
• הפצת מידע מעבר לגבולות האתר ע"י שימוש בטכנולוגית הפצה כמו RSS , TWITTER וכו' כדי להודיע למשתמשים של שינויי תוכן.

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

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

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

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

מאפיינים

אתרי Web 2.0 מאפשרים למשתמשים לעשות יותר מאשר רק לקרוא מידע. הם בונים על מתקני אינטראקטיבית לספק את "הרשת כפלטפורמה", המאפשרים למשתמשים להפעיל יישומים באמצעות הדפדפן בלבד. המשתמשים הינם הבעלים של הנתונים באתר והם בעלי השליטה עליהם.  באתרים אלה יש "ארכיטקטורה של השתתפות", אשר מעודדת את המשתמשים להוסיף ערך ליישום ככול שהם משתמשים בו. דרך זו עומד בסתירה לדרכם של אתרים מסורתים, שבהם בעל האתר מנהל את התכנים והמשתמשים באתר צופים בלבד.

אתרי 2.0 בדרך כלל  מיושמים באמצעות ממשק משתמש ידידותי ועשיר (בפונקציונאליות) המבוסס על AJAX  וספריות הרחבה לטכנולוגית הדפדפן,או בטכנולוגיות פלאג-אין (שהן ספריות החיות בדפדפן גם כן אך מצריכות התקנה נוספת מצד הגולש) כגון FLASH, ובקרוב Silverlight ו JavaFX.

כאן אני כבר נכנס לטכנולוגיות ואת זה אני אשמור לפוסט הבא.