Друга изоморфна JavaScript рамка
Sprute.js е нова изоморфна JS рамка. По време на проектирането и внедряването акцентът беше предимно върху удобството на разработката и запазването на самата рамка възможно най-проста и компактна. На първо място, това се отнася до изоморфизма.
Защо друга рамка?
В съществуващите рамки не съм доволен от подхода за внедряване на изоморфизма - целта ми беше да внедря изоморфизма по такъв начин, че да не дефинира архитектурата и да не трябва да изгражда архитектура около изоморфизма, а да го направя възможно най-прозрачен - така че да мога да напиша сървърния код по начина, по който бях свикнал, и също така работи на клиента. Моят подход може да се нарече първо страна на сървъра.
Моля ви да не ритате много заради оскъдността на текста - подробното представяне на мислите ми винаги е било слабото ми място.
Подход към изоморфизма
За да реализирам изоморфизъм, реших да „емулирам“ node.js в браузъра – изоморфният код се пише на сървъра и работи по същия начин на клиента. За да направя това, трябваше да пренеса изискването на node.js към браузъра и да емулирам файловата система. Също така пренесох частично node.js модули процес, fs, събития.
Архитектура
Стилове, скриптове, които реализират интерактивността на интерфейса и др., са събрани в теми - директория с файлове и конфигурационен обект. Това ви позволява да отделите логиката на интерфейса от останалата част от логиката; също така ви позволява да зададете отделна тема за всяка страница - удобно е при редизайн на сайт или създаване на различни админ панели и др.
Работа с данни
Пример за картографиране
Как работи
Входната точка е класът App. Когато класът се инициализира, компонентите се инициализират - работата на рамката е завършена тук. Поема работатасървърен компонент, след което рутерите се регистрират. По-нататъшната схема на работа се състои в обработка на заявки от рутери.
Състояние в момента
В момента един сайт работи по него - bel31stroy.ru и друг е в процес на разработка. Самата рамка се актуализира периодично. Заявките за изтегляне и докладите за грешки са добре дошли.
Hardcore conf в C++. Каним само професионалисти.
Чете сега
Тънкостите на Javascript/Node.js. Увеличаваме производителността десетократно
Използване на backbone.js под node.js
Коментари 49
Хей, claygod наскоро се интересуваше от RiftJS изоморфна рамка, която използва cellx за реактивност. Ако искате да вградите cellx във вашата рамка - попитайте, ще се опитам да помогна с каквото мога)) Е, самият RiftJS си струва да вземете, има много интересни идеи, за съжаление го изоставих в полза на чисто клиентска рамка.
Реактивността също често се споменава в контекста на meteor.js
operd адска привилегия Защо го правиш така? )
„Изоморфизмът“ има два плюса, с които за мен е трудно да се спори: повторно използване на кода и скорост на показване на съдържанието.
Е, не ми казвайте, но комунални услуги, помощници, услуги? И ако изградите система на интерфейси с инжектиране на зависимости? Какво ще кажете за единичните тестове? Във всеки случай въпросът не свършва с валидатори, така че напразно сте ограничени до тях. По втора точка: откъде взе идеята, че клиентът ще изреже картината по-бързо? Дори ако скриптовете са кеширани, те трябва да бъдат изтеглени-анализирани; кеширани шаблони? и се анализира отново, без това машината за шаблони не започва да създава dom / html; също така са необходими данни за изобразяване и те обикновено са последвани от http. Колкото и да се съпротивлявате, ако трезво оцените ситуацията, това наистина са два плюса. Аз неТвърдя, че всеки наистина има нужда от него и няма как без него, но това не им пречи да бъдат плюсове)
Ако приемем, че няма изобразяване на сървъра, тогава те са ненужни.
Всичко е ясно, благодаря)
Първо, защо смятате, че prerender.io е по-малката патерица? Всъщност стартирате браузъра в движение, изчаквате отговора му и след това го връщате. Изобразяването на JS, както на клиента, така и на сървъра, все още е документирана функция за браузъра и възела. Ето една още по-подробна. Второ, индексирането на сайтове с изобразяване от страна на клиента (т.е. в случая, когато JSON идва от сървъра) работи само за Google и то отскоро. Дори да забравим, че в България няма и половината от пазара за търсене, тогава Facebook, VKontakte, Skype, Twitter и още един скапан облак от сайтове все още трябва да качват съдържание.
Защо мислиш така? Прогресивното подобрение е основно принцип, който описах накратко. Изоморфизмът е един от начините за постигане на този принцип в уеб приложенията. Не е най-лесният за изпълнение, но един от най-ефективните в крайна сметка.
Също така ви съветвам да погледнете в посока на прогресивното уеб приложение на Google, един от основните принципи на тази парадигма също е прогресивното подобрение. И отново, без никакво споменаване на използването на този принцип само в рамките на CSS.
> Цитат от сайта на гугъл:
Какво е прогресивно уеб приложение? Прогресивното уеб приложение е:
Прогресивен – Работи за всеки потребител, независимо от избора на браузър, защото е изграден с прогресивно подобрение като основен принцип. Отзивчив - Пасва на всеки форм-фактор: настолен компютър, мобилен телефон, таблет или каквото и да е следващо. Независима свързаност - Подобрена с обслужващи работници за работа офлайн или в мрежи с ниско качество. Подобно на приложение - Усеща се като приложение за потребителявзаимодействия и навигация в стил на приложение, тъй като е изграден върху модела на обвивката на приложението. Свежи - Винаги актуални благодарение на процеса на актуализиране на услугата. Безопасно - Сервира се чрез HTTPS, за да се предотврати подслушване и да се гарантира, че съдържанието не е било манипулирано. Откриваем – Може да се идентифицира като „приложение“ благодарение на манифеста на W3C и обхвата на регистрация на работника на услугата, което позволява на търсачките да го намират. Повторно ангажиране - Прави повторното ангажиране лесно чрез функции като насочени известия. Може да се инсталира - Позволява на потребителите да "държат" приложенията, които намират за най-полезни, на началния си екран, без да се налага да се натоварват с магазин за приложения. С възможност за свързване - Лесно споделяне чрез URL, не изисква сложна инсталация.
Не мога да се отърва от чувството, че даваш своята интерпретация на всички концепции, без дори да изучаваш материалите. Извинете ме, но според мен „Работи за всеки потребител, независимо от избора на браузър, защото е изграден с прогресивно подобрение като основен принцип.“ достатъчно специфичен, за да се каже, че концепцията за PWA не включва просто принципа на "прогресивното подобрение", но се основава на него. В тази връзка всичко, което си написал не е нищо повече от твое лично виждане. Да, и Polymer няма нищо общо с това. Говорим за принципи и концепции.
Да, „лозунгът“ звучи по същия начин, но в случая с PWA вече не говорим за производителност без javascript. В Polymer „прогресивно подобрение“ означава способността да се използва shadi-dom в браузъри без shadow-dom, както и способността (технически осигурена от набора от компоненти на Paper и идеологията за дизайн на материали) за подаване на потребителския интерфейс „за всички устройства“ наведнъж, след което се добавят към техните нюанси, ако е необходимо/възможно. Полимерът по принцип не работи без клиентски JS според архитектурата си. Въобще не. И сървъризобразяването не е осигурено. Идеологически предната част е разделена от задната (Полимерът е само клиентски компоненти).
Можете последователно да подобрявате много различни аспекти и по много различни начини, но с думи тези подобрения, изненадващо, могат да се нарекат прогресивни/постепенни във всички случаи. Факт (а не моето виждане) е, че развитието на PWE не започва със статични страници без CSS и JS за lynx, а веднага започва със съставянето на "умни" основни компоненти. Извинете, но не звучи така, сякаш на практика разбирате за какво става въпрос в тези модни думи и теория.