Де я помиляюся щодо свого проекту та цих фреймів Javascript?


107

По-перше, головні кістки проекту, який я хочу створити, - це вікі-движок, реалізований як веб-додаток на одній сторінці. Я планую мати набір функцій, доступних під час руху, з великою кількістю доповнень для функцій вниз.

Основні характеристики

  • створення сторінки (створює вікі-статтю та дискусійний форум для цієї статті)
  • розмітка та WYSIWYG ала розмітка
  • на ходу перетворення між розміткою / html / WYSIWYG
  • бічна смужка для швидкої навігації
  • верхню панель інструментів для вибору редагування / перегляду

Додаткові функції

  • налаштована бічна панель для навігації за допомогою іншого способу
  • налаштована панель інструментів (можливо, додайте мову вибору розмітки)
  • теги
  • редаговані Тодо
  • перетягуйте завантаження файлів та вкладення зображень

Двигун спочатку складався б із найпростішого створення сторінки, розмітки та редагування WYSIWYG та збереження. Зрештою, я хотів би розширити цей основний механізм за допомогою підтримки перетягування зображень, завантаження файлів, графіків даних у реальному часі та бічної панелі для налаштування переглядів.

Я здійснив досить широкий пошук гідного проекту, на якому можна було б базувати свій проект, але крім TiddlyWiki, схоже, немає хороших вікі-двигунів на основі JavaScript. Я також розглядав питання про те, щоб застосувати Jquery поверх існуючих вікі-двигунів, але я вважаю, що в кінцевому підсумку я все-таки перепишу його (плюс його просто цікавіше додати функції, які я хочу, коли я йду). У будь-якому випадку я прийшов до впровадження цього звіра за допомогою бібліотеки javascript +.

Я знаю, що реально не можна порівнювати деякі ці рамки один з одним, оскільки вони дуже не є яблуками, а яблуками. Я намагався створити будь-які коментарі / питання порівняння щодо порівнянних фрагментів відповідних рамок, але я готовий до виправлення.

Отже, ми йдемо:

На основі власних досліджень та думок я звузив список до пунктів нижче. Я навмисно відмовився від таких речей, як SproutCore, corMVC, YUI та інші, тому що я, будучи обмеженою можливістю, вважав, що наведені нижче елементи краще підходять.

Мої параметри


jquery / UI + backbonejs

Загалом

З того, що я прочитав, ця комбінація використовується і улюбленою багатьма і дуже гнучка і розширювана. Моє основне занепокоєння полягає в тому, що ця комбінація просто не є найкращим стрибком для розробки більш орієнтованого на робочий стіл інтерфейсу інтерфейсу.

UI

Незважаючи на те, що jQueryUI або jqueryTools можуть бути конкурентоспроможними, вони, звичайно, не відповідають рівним можливостям інтерфейсу інших фреймворків. Зокрема, вони здаються важкими для ефектів, але їм не вистачає пристойної підтримки зрізування макета.

javascriptMVC

Загалом

Для мене JavascriptMVC виглядає так, що це по суті розширення jquery + MVC (jqueryMX), а також кілька інших додатків для документування (documentJS), функціональних тестів (funcUnit) та управління кодом і залежностями (stealJS). Окрім переваг додаткового модуля, я думаю, що функціональна дискусія дійсно зводиться до backbonejs vs. jqueryMX. Чи правильно я погоджуюсь на цьому і чи працював хто з або порівнював обидва?

UI

JavascriptMVC додає елементи MXUI понад усе, що є в наявності для Jquery, так що я думаю, щонайменше, це невелика перемога в цій категорії.

нокаутс

Загалом

Мої думки та занепокоєння з цього приводу дуже схожі на коментарі jquery + основні. Вони, схоже, пропонують схожі функції, але просто з іншого погляду. Часто вказаним недоліком є ​​те, що нокаути з’єднують бізнес-логіку та презентацію занадто тісно з прив'язкою даних і що цей метод прив'язки може порушити складну взаємодію з інтерфейсом, але я хотів би почути, чому це не проблема.

UI

Порожній на даний момент

Dojo & ExtJS

Загалом

Я збираюся поєднати дискусію Dojo та ExtJS, тому що я про них знаю найменше, і вони, схоже, грають майже в одному просторі. Більшість інформації про stackoverflow про цих двох видаються застарілими. З того, що я бачив, це те, що вони є великими рамками, які добре підходять для впровадження додатків калібру на робочому столі. Доджо був висловлений у зв'язку з поганою документацією, але, здається, це вже не так. Конечно, ExtJS має комерційну ліцензію, але це дійсно розумно для того, що ви отримуєте, і я не став би проти цього занадто сильно. Віджети в ExtJS здаються дещо професійніше зробленими, ніж Dojo, але я, безумовно, там можу виправитись. Мені було б цікаво почути від кожного, хто має досвід обох.

UI

У Dojo є бібліотека інтерфейсу Dijit, у ExtJS є функції інтерфейсу, але вони не в ядрі Ext. Ось документація і ось їх демонстрація

Капучино

Загалом

А тут є капучино. Ні CSS, ні html, але також може бути важко використовувати існуючі бібліотеки javascript. Objective-J не здається страшним, особливо враховуючи, що вони також можуть писати звичайний JavaScript. Демонстраційні версії вражають і, здається, близько наближаються до потреб користувальницького інтерфейсу у двигуні wiki. API на основі какао потрібно багато взяти для того, хто з ним не знайомий, але, можливо, воно того варте. Я чув, що з механізмом компонування не завжди легко працювати, але молодий і, можливо, руйнівний технік, як це, безумовно, матиме деякі недоліки.

UI

Порожній на даний момент

Я прошу вибачення за те, що написав так багато, але ей, принаймні, це не сокира проти y питання з надією на багато дешевих відповідей. Так що ж ви думаєте? Що має бути основою для мого робочого столу, як wiki engine, який, з надією, з часом стане більш багатим на функції (читати складні)?


9
+1 за неймовірно детальне та продумане запитання!
Шон Віейра

8
Не впевнений у своїй часовій шкалі та ресурсах, але коли я намагаюся вирішувати між декількома рамками / середовищами, я просто йду вперед і намагаюся швидко побудувати прототип. Навіть якщо це лише одна-дві основні функції, я вважаю, що всі дослідження та документація у світі ніколи не збігаються зі спробами побудувати щось із інструментів. Я кажу, взяти день з кожним і подивитися, як далеко ви дістаєтесь. Це дасть вам досить непогану інформацію про те, які інструменти підходять до вирішення завдань, і ви відчуваєте себе найбільш комфортно.
Брайан Фланаган

1
@Brian Flanagan Перейдіть до відповіді - навіть якщо "мета".

1
Ви подивилися на tiddlywiki.com , я думаю, що це чиста самодостатня вікі, зроблена в JavaScript
Бернхард

Так, я подивився на tiddlywiki. Багато в чому це натхнення для цього проекту, але я маю власну базу та напрямок для цього проекту.
funkyeah

Відповіді:


4

Я б запропонував спочатку розробити конкретні вимоги до інтерфейсу для вашого проекту. Який із рамок, які ви пробували, ви взяли за спін?

Особисто я потрапив у розробку ExtJS, тому що проекти, над якими я працюю, потребують великого налаштування елементів керування / віджетів. У ExtJS є тонна їх прямо з коробки, і її завжди можна розширити, комбінувати або занурити в будь-яку жахливість, яку вимагає ваш бізнес.

ExtJS 4 також дозволяє « нанести на шкіру» інтерфейс користувача, щоб додатково налаштувати зовнішній вигляд.

Якщо ви новачок у JavaScript і вам комфортно користуватися Java, ви можете навіть заглянути в серверне рішення, таке як GWT , JSF або навіть Vaadin


19

Не впевнений у своїй часовій шкалі та ресурсах, але коли я намагаюся вирішувати між декількома рамками / середовищами, я просто йду вперед і намагаюся швидко побудувати прототип. Навіть якщо це лише одна-дві основні функції, я вважаю, що всі дослідження та документація у світі ніколи не збігаються зі спробами побудувати щось із інструментів. Я кажу, взяти день з кожним і подивитися, як далеко ви дістаєтесь. Це дасть вам досить непогану інформацію про те, які інструменти підходять до вирішення завдань, і ви відчуваєте себе найбільш комфортно.


6

В даний час все це лють ( найпопулярніша повнозмінна рамка JavaScript на GitHub і Meteorpedia - це вікі-движок, написаний на Meteor.

Запуск відео познайомить вас зачепили 1:28.

Це агностик відносно призначеного для користувача інтерфейсу, і було протестовано з Bootstrap і Famo.us . Він також генерує мобільні додатки з тієї ж кодової бази.


1
І є інтеграція з React, але це лише для людей, які на 100% в цьому. Також немає проблем із використанням плагінів jquery та бібліотек малювання svg / canvas з великою кількістю знань про Meteor.
imslavko

1

Вибір рамки може не обмежувати вибір інтерфейсу користувача настільки, наскільки ви можете собі уявити. Ця недавня стаття Анрі Бергіуса про роз'єднання управління вмістом ілюструє суть набагато краще, ніж я міг, - і, до речі, посилання на досить солодкий на вигляд чистий JavaScript -редактор вмісту на JavaScript .


Я звичайно копаю редактор aloha для WYSIWYG. Я б точно встановив його у верхній частині екрана і додав би вкладки для перегляду текстової області в розміті певного формату. Іншим моїм головним варіантом буде деякий аромат markItUp .
funkyeah

1

Ти не самотній!

VanillaJS і Ampersand .. - чудові приклади серйозного диска для більш простого і модульного JavaScript.

Про це навіть є Книга .

Простота керується заниженою функцією es6: Модулі та стандарт впровадження SystemJS . Він навіть може бути використаний у системах non-es6.

Як класно це!


1

Я б сказав, що ви помиляєтесь у своєму загальному виборі кандидатів, оскільки ви опускаєте Angular та Ember, обидва вони краще підходять, ніж будь-яка з інших перерахованих рамок.

Загалом, я б сказав, що Angular.js є основою для цього.

Акцент на маршрутизації

Більшість того, про що ви говорите (кілька бічних панелей для навігації, додаток на одній сторінці) - це функції маршрутизації або те, як інтерфейс інтерпретує текст на навігаційній панелі URL-адреси.

І Angular.js, і Ember мають відмінні маршрутизатори, які дозволяють виконувати все необхідне без додаткового коду.

Для вашої користі, ось швидка розбивка функцій у Angular, які можна використовувати для створення вашої вікі на одній сторінці

Структура самого сайту

Angular має дивовижну бібліотеку під назвою маршрутизатор інтерфейсу, що дозволяє вам створити користувальницьку навігацію та створити зручну для SEO структуру розкриття вашого вмісту. Кілька переглядів дозволять також і верхню панель інструментів.

Підручник із маршрутизатором для інтерфейсу: http://cacodaemon.de/index.php?id=57

WYSIWYG редактор

Кутовий побудований на живій двосторонній прив'язці (коли щось десь зміниш, він автоматично змінюється скрізь в іншому місці). Тому він поставляється з великою кількістю функцій, які добре працюють з таким редактором. Кілька хороших вже зроблені, і вам потрібно лише їх здійснити.

http://textangular.com/

Графіки та інші акуратні речі

Кутові директиви призначені для таких дій, як створення компонентів Chart, які можна використовувати багаторазово. Вони не зовсім інші, ніж Wordpress віджети. Багато з них уже розроблені і можуть бути включені до вашого проекту Angular.

http://www.sitepoint.com/creating-charting-directives-using-angularjs-d3-js/

Щодо Ембер, я мало про це знаю, тому не можу говорити про його особливості.


0

Одне з пропозицій щодо Backbone, якщо ви вирішили його використовувати, ви повинні піти на Marionnete, оскільки це Backbone, але з кращою архітектурною структурою і більш виразним (я особисто вважаю, що Backbone не встановлює ніяких вказівок, і це відчувається як зворотний бік у великих додатках) .

Я працював з ним протягом декількох місяців, комбінуючи різні js libs, і не заважає, як інші рамки, і конвеєр повідомлень - це дійсно хороший спосіб підключення компонентів через додаток, але тримати їх роз'єднання.

Ось у вас чудова розмова, яка змусила мене вирішити це: https://www.youtube.com/watch?v=qWr7x9wk6_c

І ось у вас демонстраційний прототип, який також містить елемент перетягування та інші js-ліфти. Я хотів би почути, що ви думаєте про мій код, оскільки я вже 1,5 року працюю над веб-розробкою ... Я все ще новачок: https://github.com/Drasky-Vanderhoff/marionette-demo/

Про Knockout, це дійсно добре, якщо ви хочете взаємодія з уже наявним вмістом, і ви не будете постійно з'єднуватися з бекендом. Я працював з ним протягом 6 місяців, і в кінцевому підсумку мені потрібно було використовувати багато інших js libs для маршрутизації; плюс я в кінцевому підсумку повторюю багато структур, які мають Backbone та інші JS Frameworks. Що я скажу, це те, що він взагалі не заважає вам і стане інструментом, а не обмеженням. Також це було майже рік тому, тому кілька речей змінилося.

Одне, якщо ви знайдете Knockback (Knockout + Backbone) ... уникайте цього, документація не така хороша, як повинна бути, і вам знадобиться набагато більше часу, щоб її вивчити. Якщо ви хочете піти на це, спершу складіть швидкий прототип, щоб зрозуміти, чи є те, що ви хочете.


Минув рік, як ви опублікували це. Оскільки я зараз хочу розпочати нову розробку, чи все ще Маріонетта залишається вашим найкращим вибором для розробки Javascript?
AlVaz

Зовсім не зараз, краще зараз з Angular.js або React.js (ви можете комбінувати обидва, якщо хочете). Якщо ви хочете як мобільну, так і веб-версію програми, я настійно пропоную вам скористатися React.js, оскільки React Native використовується для створення власних додатків для iOS та Android. І React.js, і рідний поділяють однакові поняття, структури та парадигми (це вчитися один раз, використовувати всюди, знаючи React.js == React Native, так, я не використовую потрійні рівні: P)
DraskyVanderhoff

Також є веб-компоненти, що використовують полімер, і я настійно пропоную вам перевірити це, якщо ви хочете працювати з, мабуть, найгарячішими рамками наступного року. Нарешті, Meteor - це чудовий варіант, якщо вам потрібна 100% синхронізація даних у режимі реального часу / тристороння прив'язка даних, особливо тому, що якщо ви пишете валідатори для парам, він запускатиме той самий валідатор як у бекенді, так і у фронте, уникайте необхідності наявності 2 коду бази однакові.
DraskyVanderhoff

Одне уточнення, я ніколи не говорив, що Маріонетта був моїм найкращим вибором (на той час це був насправді кутовий), що я сказав, що якщо ви збираєтесь використовувати Backbone.js ТОМИ використовувати Marionette.js замість цього.
DraskyVanderhoff
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.