Dove mi sbaglio sul mio progetto e su questi framework Javascript?


107

Prima di tutto, l'essenza del progetto che desidero creare è un motore wiki implementato come un'app web a pagina singola. Ho intenzione di avere una serie di funzionalità disponibili sin dall'inizio con molte aggiunte di funzionalità lungo la strada.

Caratteristiche di base

  • creazione della pagina (crea sia l'articolo wiki che il forum di discussione per quell'articolo)
  • markup e WYSIWYG ala markitup
  • conversione al volo tra markup / html / WYSIWYG
  • una barra laterale per navigare velocemente
  • una barra degli strumenti superiore per la scelta di modifica / visualizzazione

Funzionalità avanzate

  • barra laterale configurabile per navigare con metodi diversi
  • barra degli strumenti configurabile (eventualmente aggiungere un linguaggio di markup preferito)
  • tag
  • cose da fare modificabili
  • trascina e rilascia i caricamenti di file e gli allegati di immagini

Il motore originariamente consisteva nella creazione di pagine, markup, editing e salvataggio WYSIWYG più elementari. Alla fine vorrei estendere questo motore di base con il supporto di immagini drag and drop, caricamenti di file, grafici di dati in tempo reale e una barra laterale per la personalizzazione delle visualizzazioni.

Ho fatto una ricerca abbastanza ampia per un progetto decente da cui basare il mio progetto, ma a parte TiddlyWiki non sembra esserci alcun buon motore wiki basato su javascript. Ho anche considerato di applicare Jquery in cima ai motori wiki esistenti, ma credo che alla fine avrei finito per riscriverlo comunque (in più è solo più eccitante aggiungere le funzionalità che voglio mentre procedo). In ogni caso sono arrivato all'implementazione di questa bestia con una libreria javascript + framework.

So che non si possono davvero confrontare alcuni di questi quadri l'uno con l'altro in quanto non sono affatto mele rispetto alle mele. Ho provato a inquadrare eventuali commenti / domande di confronto con parti comparabili dei rispettivi framework, ma sono aperto a essere corretto.

Quindi eccoci qui:

Sulla base delle mie ricerche e delle mie opinioni, ho ristretto l'elenco agli elementi seguenti. Ho intenzionalmente omesso cose come SproutCore, corMVC, YUI e altri poiché, nella mia capacità limitata, pensavo che gli elementi seguenti sarebbero stati più adatti.

Le mie opzioni


jquery / UI + backbonejs

Complessivamente

Da quello che ho letto questa combinazione è usata e amata da molti ed è molto flessibile ed estensibile. La mia principale preoccupazione è che questa combinazione non è semplicemente il miglior punto di partenza per lo sviluppo dell'interfaccia utente più orientata al desktop.

UI

Sebbene jQueryUI o jqueryTools possano essere competitivi, certamente non sembrano essere alla pari con le capacità dell'interfaccia utente di altri framework. Nello specifico sembrano essere pesanti sugli effetti ma privi di un supporto decente per l'affettatura del layout.

javascriptMVC

Complessivamente

JavascriptMVC a me sembra che sia essenzialmente jquery + MVC (jqueryMX) estensioni, insieme ad alcune altre app per la documentazione (documentJS), i test funzionali (funcUnit) e la gestione del codice e delle dipendenze (stealJS). Al di là dei vantaggi del modulo aggiuntivo, penso che il dibattito funzionale si riduca davvero a backbonejs vs jqueryMX Ho ragione su questo e qualcuno ha lavorato con o confrontato entrambi?

UI

JavascriptMVC aggiunge gli elementi MXUI in cima a tutto ciò che è disponibile per Jquery, quindi penso che sia almeno una leggera vittoria in quella categoria.

knockoutjs

Complessivamente

I miei pensieri e le mie preoccupazioni su questo su questo sono molto simili ai commenti di jquery + backbone. Entrambi sembrano offrire caratteristiche simili ma solo da una prospettiva diversa. Uno svantaggio spesso citato è che knockoutjs accoppia la logica di business e la presentazione troppo strettamente con il data-bind e che questo metodo di associazione può interrompersi per un'interazione complessa dell'interfaccia utente, ma mi piacerebbe sapere perché non è un problema.

UI

Vuoto al momento

Dojo ed ExtJS

Complessivamente

Combinerò la discussione su Dojo ed ExtJS perché ne so poco e sembrano suonare quasi nello stesso spazio. La maggior parte delle informazioni sullo stackoverflow su questi due sembra essere obsoleta. Da quello che ho visto è che sono entrambi framework di grandi dimensioni che sono buoni per l'implementazione di app di calibro desktop. Dojo era stato rimproverato per scarsa documentazione, ma sembra che non sia più così. ExtJS ovviamente ha la licenza commerciale, ma è davvero ragionevole per quello che ottieni e non lo terrei troppo. I widget in ExtJS sembrano essere fatti un po 'più professionalmente di Dojo, ma potrei certamente essere corretto lì. Sarei interessato a sentire chiunque abbia esperienza in entrambi.

UI

Dojo ha la libreria dijit UI ExtJS ha funzionalità UI ma non sono nel core Ext. Ecco la documentazione e qui ci sono le loro demo

Cappuccino

Complessivamente

E poi c'è il cappuccino. Nessun CSS, nessun HTML, ma potrebbe anche essere difficile utilizzare le librerie javascript esistenti. Objective-J non sembra spaventoso, soprattutto considerando che sono in grado di scrivere anche javascript semplici. Le demo sono impressionanti e sembrano avvicinarsi da vicino alle esigenze dell'interfaccia utente per il motore wiki. L'API basata sul cacao è molto da accettare per qualcuno che non la conosce, ma forse ne vale la pena. Ho sentito che il motore di layout non è sempre facile da lavorare, ma una tecnologia giovane e forse dirompente come questa avrà sicuramente alcuni difetti.

UI

Vuoto al momento

Mi scuso per aver scritto così tanto ma hey, almeno non è una domanda ax vs y vs z sperando in tonnellate di risposte economiche. Allora, cosa ne pensate? Quale dovrebbe essere la base per il mio desktop come il motore wiki, che si spera diventerà più ricco di funzionalità (complesso di lettura) nel tempo?


9
+1 per una domanda incredibilmente dettagliata e ben ponderata!
Sean Vieira

8
Non sono sicuro della tua sequenza temporale e delle tue risorse, ma quando provo a decidere tra più framework / ambienti, vado avanti e cerco di costruire rapidamente un prototipo. Anche se sono solo una o due funzioni principali, trovo che tutta la ricerca e la documentazione nel mondo non corrisponderanno mai al tentativo di costruire qualcosa con gli strumenti. Dico prenditi un giorno con ciascuno e guarda quanto lontano arrivi. Questo ti darà una buona indicazione di quali strumenti sono all'altezza del compito e ti fanno sentire più a tuo agio.
Brian Flanagan

1
@Brian Flanagan Passa a una risposta, anche se "meta".

1
Hai guardato tiddlywiki.com , penso che sia un puro wiki auto-contenente fatto in JavaScript
Bernhard

Sì, ho guardato tiddlywiki. Per molti versi è l'ispirazione per questo progetto, ma ho la mia base e la mia direzione previste per questo progetto.
funkyeah

Risposte:


4

Suggerirei prima di venire con i requisiti dell'interfaccia utente specifici per il tuo progetto. Quale dei framework che hai provato hai preso per fare un giro?

Personalmente, sono entrato nello sviluppo di ExtJS perché i progetti su cui lavoro richiedono molta personalizzazione dei controlli / widget. ExtJS ne ha un sacco fuori dagli schemi e può sempre essere esteso, combinato o trasformato in qualsiasi mostruosità richiesta dalla tua attività.

ExtJS 4 ti consente anche di "personalizzare" la tua interfaccia utente per personalizzarne ulteriormente l'aspetto.

Se sei nuovo in JavaScript e hai dimestichezza con Java, potresti persino cercare una soluzione lato server come GWT , JSF o persino Vaadin


19

Non sono sicuro della tua sequenza temporale e delle tue risorse, ma quando provo a decidere tra più framework / ambienti, vado avanti e cerco di costruire rapidamente un prototipo. Anche se sono solo una o due funzioni principali, trovo che tutta la ricerca e la documentazione nel mondo non corrisponderanno mai al tentativo di costruire qualcosa con gli strumenti. Dico prenditi un giorno con ciascuno e guarda quanto lontano arrivi. Questo ti darà una buona indicazione di quali strumenti sono all'altezza del compito e ti fanno sentire più a tuo agio.


6

è di gran moda al giorno d'oggi (il framework JavaScript full-stack più famoso su GitHub e Meteorpedia è un motore wiki scritto in Meteor.

Il video di lancio ti conquisterà per 1:28.

È agnostico per quanto riguarda l'interfaccia utente, ed è stato testato ampiamente con Bootstrap e Famo.us . Genera anche app mobili dalla stessa base di codice.


1
E ci sono integrazioni con React, ma questo è solo per le persone che ci sono al 100%. Inoltre, non ci sono problemi nell'utilizzo dei plugin jquery e delle librerie di disegno svg / canvas senza molta conoscenza di Meteor.
imslavko

1

La scelta del framework potrebbe non limitare le scelte dell'interfaccia utente tanto quanto potresti immaginare. Questo recente articolo di Henri Bergius sul disaccoppiamento della gestione dei contenuti illustra il punto molto meglio di quanto potrei fare e, per inciso, si collega a un editor di contenuti sul posto puro JavaScript (indipendente dal framework) piuttosto carino .


Sto sicuramente cercando l'editor di aloha per WYSIWYG. Lo ancorerei sicuramente nella parte superiore dello schermo e aggiungerei schede per visualizzare l'area di testo anche nel markup di alcuni formati. La mia altra opzione principale sarebbe un po 'di sapore di markItUp .
funkyeah

1

Non sei solo!

VanillaJS e Ampersand .. sono ottimi esempi della spinta seria per JavaScript più semplice e modulare.

C'è persino un libro a riguardo.

La semplicità è guidata da una caratteristica es6 sottovalutata: i moduli e lo standard di implementazione SystemJS . Può essere utilizzato anche su sistemi non ES6.

Quant'è fico!


1

Direi che hai torto nella scelta complessiva dei candidati poiché stai omettendo Angular ed Ember, che sono entrambi più adatti di qualsiasi altro framework elencato.

Nel complesso, direi che Angular.js è il framework per questo.

Enfasi sul routing

Molto di ciò di cui parli (diverse barre laterali per la navigazione, un'app a pagina singola) sono funzioni di routing o il modo in cui il front-end interpreta il testo nella barra di navigazione dell'URL.

Sia Angular.js che Ember hanno router eccellenti che ti consentono di realizzare tutto ciò di cui hai bisogno senza codice aggiuntivo.

A tuo vantaggio, ecco una rapida ripartizione delle funzionalità in Angular che possono essere utilizzate per creare il tuo wiki a pagina singola

La struttura del sito stesso

Angular ha una straordinaria libreria chiamata UI router che ti consente sia di creare una navigazione personalizzata sia di impostare una struttura SEO friendly per rivelare i tuoi contenuti. Viste multiple consentirebbero anche una barra degli strumenti superiore.

Esercitazione sul router dell'interfaccia utente: http://cacodaemon.de/index.php?id=57

Editor WYSIWYG

Angular è costruito su un legame bidirezionale live (quando si cambia qualcosa da qualche parte, cambia automaticamente ovunque.) Pertanto viene fornito con molte funzionalità che funzionano bene con questo tipo di editor. Alcuni buoni sono già stati fatti e devi solo implementarli.

http://textangular.com/

Grafici e altre cose interessanti

Le direttive angolari sono progettate per eseguire operazioni come la creazione di componenti di grafici riutilizzabili. Non sono totalmente diversi dai widget di Wordpress. Molti di questi sono già stati sviluppati e possono essere inseriti nel tuo progetto Angular.

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

Per quanto riguarda Ember, non ne so molto quindi non posso parlare delle sue caratteristiche particolari.


0

Un suggerimento su Backbone, se decidi di usarlo dovresti scegliere Marionnete poiché è Backbone ma con una struttura architettonica migliore e più supponente (personalmente ritengo che Backbone non stabilisca alcuna linea guida e questo sembra un aspetto negativo nelle app di grandi dimensioni) .

Ci ho lavorato per alcuni mesi combinando diverse librerie js e non ti intralcia come altri framework e la pipeline dei messaggi è davvero un buon modo per connettere i componenti attraverso l'app ma tenerli disaccoppiati.

Ecco un bel discorso che mi ha fatto decidere per questo: https://www.youtube.com/watch?v=qWr7x9wk6_c

E qui hai un prototipo demo che ha anche l'elemento drag and drop più altre librerie js collegate. Mi piacerebbe sapere cosa ne pensi del mio codice dato che lavoro da 1,5 anni allo sviluppo web ... sono ancora un principiante: https://github.com/Drasky-Vanderhoff/marionette-demo/

A proposito di Knockout, è davvero buono se vuoi l'interazione con il contenuto che hai già e non ti connetti costantemente con il backend. Ci ho lavorato per 6 mesi e finisco per aver bisogno di usare molte altre librerie js per il routing; inoltre finisco per ripetere molte delle strutture che Backbone e altri JS Frameworks finiscono per avere. Quello che dirò è che non si intrometterà affatto e sarà uno strumento piuttosto che un vincolo. Anche questo è stato quasi un anno fa, quindi alcune cose sono cambiate.

Una cosa, se trovi Knockback (Knockout + Backbone) ... evitalo, la documentazione non è buona come dovrebbe essere e ti ci vorrà molto più tempo per impararla. Se vuoi provarlo, crea prima un prototipo veloce per vedere se è quello che vuoi.


È passato un anno da quando l'hai postato. Dato che sto cercando di iniziare un nuovo sviluppo ora, Marionette è ancora la tua prima scelta per lo sviluppo di Javascript?
AlVaz

Niente affatto, in questo momento è meglio con Angular.js o React.js (puoi combinare entrambi se vuoi). Se desideri sia la versione mobile che quella web per un'app, ti consiglio vivamente di utilizzare React.js poiché React Native viene utilizzato per creare app native per iOS e Android. Sia React.js che native condividono gli stessi concetti, strutture e paradigma (è Impara una volta, usa ovunque, Knowing React.js == React Native, sì, non sto usando il triplo uguale: P)
DraskyVanderhoff

Inoltre ci sono componenti Web che utilizzano Polymer che ti consiglio vivamente di verificarlo se vuoi lavorare con probabilmente il framework più caldo del prossimo anno. Infine, Meteor è un'ottima opzione se hai bisogno di sincronizzazione dei dati in tempo reale al 100% / associazione dati a tre vie, specialmente perché se scrivi validatori per params eseguirà lo stesso validatore sia nel backend che nel frontend, evita la necessità di avere 2 codici basi che sono le stesse.
DraskyVanderhoff

Un chiarimento, non ho mai detto che Marionette fosse la mia prima scelta (in realtà era Angular a quel tempo) quello che avevo detto era che SE userai Backbone.js LORO usa Marionette.js invece.
DraskyVanderhoff
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.