Em primeiro lugar, o esqueleto do projeto que desejo criar é um mecanismo wiki implementado como um aplicativo da web de uma única página. Planejo ter um conjunto de recursos disponíveis desde o início, com muitas adições de recursos no futuro.
Recursos básicos
- criação de página (cria artigo wiki e fórum de discussão para esse artigo)
- marcação e WYSIWYG ala markitup
- conversão instantânea entre markup / html / WYSIWYG
- uma barra lateral para navegar rapidamente
- uma barra de ferramentas superior para escolher editar / visualizar
Características avançadas
- barra lateral configurável para navegar por meio de método diferente
- barra de ferramentas configurável (possivelmente adicionar linguagem de marcação de sua escolha)
- Tag
- tarefas editáveis
- arrastar e soltar uploads de arquivos e anexos de imagens
O mecanismo consistiria originalmente na criação, marcação e edição WYSIWYG mais básicas e salvamento. Eu gostaria de estender esse mecanismo básico com suporte para arrastar e soltar imagens, uploads de arquivos, gráficos de dados ativos e uma barra lateral para personalizar visualizações.
Fiz uma busca bastante extensa por um projeto decente do qual basear meu projeto, mas além do TiddlyWiki, não parece haver nenhum bom mecanismo wiki baseado em javascript. Também considerei aplicar o Jquery em cima dos mecanismos wiki existentes, mas acredito que acabaria reescrevendo-o eventualmente (Além disso, é apenas mais emocionante adicionar os recursos que desejo enquanto prossigo). De qualquer forma, cheguei a implementar esta besta com uma biblioteca + framework javascript.
Eu sei que não se pode realmente comparar algumas dessas estruturas umas com as outras, pois elas não são muito comparáveis. Tentei enquadrar quaisquer comentários / perguntas de comparação em partes comparáveis das respectivas estruturas, mas estou aberto a ser corrigido.
Aqui vamos nos:
Com base em minhas próprias pesquisas e opiniões, reduzi a lista aos itens abaixo. Eu intencionalmente deixei de fora coisas como SproutCore, corMVC, YUI e outros porque eu, em minha capacidade limitada, pensei que os itens abaixo seriam um ajuste melhor.
Minhas opções
jquery / UI + backbonejs
No geral
Pelo que li, essa combinação é usada e amada por muitos e é muito flexível e extensível. Minha maior preocupação é que essa combinação simplesmente não é o melhor ponto de partida para desenvolver a interface de IU mais orientada para desktop.
UI
Embora jQueryUI ou jqueryTools possam ser competitivos, eles certamente não parecem estar no mesmo nível dos recursos de IU de outros frameworks. Especificamente, eles parecem ter muitos efeitos, mas faltam um suporte decente de corte de layout.
javascriptMVC
No geral
JavascriptMVC para mim parece ser essencialmente extensões jquery + MVC (jqueryMX), junto com alguns outros aplicativos para documentação (documentJS), testes funcionais (funcUnit) e gerenciamento de código e dependência (stealJS). Além dos benefícios do módulo adicional, acho que o debate funcional realmente se resume a backbonejs x jqueryMX. Estou correto nisso e alguém trabalhou ou comparou os dois?
UI
JavascriptMVC adiciona os itens MXUI em cima de tudo o que está disponível para Jquery, então eu acho que é, no mínimo, uma pequena vitória nessa categoria.
knockoutjs
No geral
Meus pensamentos e preocupações sobre isso são muito semelhantes aos comentários do jquery + backbone. Ambos parecem oferecer recursos semelhantes, mas apenas de uma perspectiva diferente. Uma desvantagem frequentemente citada é que o knockoutjs une a lógica de negócios e a apresentação com muita força ao data-bind e que esse método de vinculação pode quebrar para uma interação de interface de usuário complexa, mas eu adoraria saber por que isso não é um problema.
- Discussão de conceitos de backbone vs knockoutJS
- Características de knockoutjs
UI
Em branco no momento
Dojo e ExtJS
No geral
Vou combinar a discussão Dojo e ExtJS porque sei o menos sobre eles e eles parecem jogar quase no mesmo espaço. A maioria das informações sobre stackoverflow sobre esses dois parece estar desatualizada. Pelo que vi é que ambos são grandes frameworks que são bons para implementação de aplicativos de calibre desktop. Dojo foi repreendido pela documentação deficiente, mas parece que não é mais o caso. É claro que ExtJS tem a licença comercial, mas é realmente razoável para o que você obtém e eu não consideraria isso muito contra. Os widgets no ExtJS parecem ser feitos de maneira um pouco mais profissional do que no Dojo, mas eu certamente poderia ser corrigido lá. Eu gostaria de ouvir de alguém que tenha experiência em ambos.
UI
O Dojo possui a biblioteca de IU dijit ExtJS possui recursos de IU, mas eles não estão no núcleo Ext. Aqui está a documentação e aqui estão suas demonstrações
Cappuccino
No geral
E depois há o Cappuccino. Sem CSS, sem html, mas também pode ser difícil usar as bibliotecas javascript existentes. Objective-J não parece muito assustador, especialmente considerando que eles também são capazes de escrever javascript puro. As demonstrações são impressionantes e parecem se aproximar das necessidades da interface do usuário para o mecanismo wiki. A API baseada em cacau é muito para alguém que não está familiarizado com ela, mas talvez valha a pena. Ouvi dizer que nem sempre é fácil trabalhar com o mecanismo de layout, mas uma tecnologia jovem e possivelmente inovadora como essa certamente terá algumas deficiências.
UI
Em branco no momento
Peço desculpas por escrever tanto, mas hey, pelo menos não é a questão ax vs y vs z esperando por toneladas de respostas baratas. Então, o que você acha? Qual deve ser a base para o meu desktop como o motor wiki, que se tornará mais rico em recursos (leia-se complexo) com o tempo?
fonte
Respostas:
Eu sugeriria primeiro chegar a requisitos específicos de interface do usuário para seu projeto. Quais dos frameworks que você experimentou você deu uma volta?
Pessoalmente, entrei no desenvolvimento de ExtJS porque os projetos em que trabalho exigem muita customização de controles / widgets. ExtJS tem uma tonelada deles direto da caixa e pode sempre ser estendido, combinado ou misturado em qualquer monstruosidade que seu negócio exigir.
ExtJS 4 também permite que você "skin" sua IU para personalizar ainda mais a aparência.
Se você é novo em JavaScript e se sente confortável com Java, pode até procurar uma solução do lado do servidor, como GWT , JSF ou mesmo Vaadin
fonte
Não tenho certeza sobre sua linha do tempo e recursos, mas quando estou tentando decidir entre vários frameworks / ambientes, eu apenas prossigo e tento construir um protótipo rapidamente. Mesmo que seja apenas uma ou duas funções principais, acho que toda a pesquisa e documentação do mundo nunca será compatível com a tentativa de construir algo com as ferramentas. Eu digo: tire um dia com cada um e veja o quão longe você chega. Isso lhe dará uma boa indicação de quais ferramentas são adequadas para a tarefa e são mais confortáveis para você.
fonte
meteoroestá na moda hoje em dia (o framework JavaScript full-stack mais famoso no GitHub e no Meteorpedia é um mecanismo wiki escrito em Meteor.
O vídeo de lançamento o deixará fisgado por 1:28.
É agnóstico com relação à interface do usuário, e foi testado extensivamente com Bootstrap e Famo.us . Ele também gera aplicativos móveis a partir da mesma base de código.
fonte
Sua escolha de estrutura pode não restringir suas escolhas de IU tanto quanto você pode estar imaginando. Este artigo recente de Henri Bergius sobre o desacoplamento do gerenciamento de conteúdo ilustra o ponto muito melhor do que eu poderia - e, incidentalmente, links para um editor de conteúdo local de puro JavaScript (independente de estrutura) de aparência agradável .
fonte
Você não está sozinho!
VanillaJS e Ampersand .. são ótimos exemplos do sério impulso para um JavaScript mais simples e modular.
Existe até um livro sobre isso.
A simplicidade está sendo impulsionada por um recurso es6 subestimado: Módulos e o padrão de implementação SystemJS . Ele ainda pode ser usado em sistemas não-ES6.
Quão legal é isso!
fonte
Eu diria que você está errado na escolha geral dos candidatos, pois está omitindo Angular e Ember, que são mais adequados do que qualquer uma das outras estruturas listadas.
No geral, eu diria que Angular.js é a estrutura para este.
Ênfase no roteamento
Muito do que você está falando (várias barras laterais para navegação, um aplicativo de página única) são funções de roteamento ou como o front end interpreta o texto na barra de navegação de URL.
Tanto o Angular.js quanto o Ember têm roteadores excelentes que permitem realizar tudo o que você precisa sem código adicional.
Para seu benefício, aqui está uma análise rápida dos recursos do Angular que podem ser usados para criar seu wiki de página única
A própria estrutura do site
O Angular tem uma biblioteca incrível chamada roteador de interface do usuário que permite a você criar uma navegação personalizada e configurar uma estrutura amigável de SEO para revelar seu conteúdo. Múltiplas visualizações permitiriam uma barra de ferramentas superior também.
Tutorial do roteador Ui: http://cacodaemon.de/index.php?id=57
Editor WYSIWYG
O Angular é baseado em vinculação bidirecional ativa (quando você altera algo em algum lugar, ele muda automaticamente em qualquer outro lugar). Portanto, ele vem com muitos recursos que funcionam bem com esse tipo de editor. Alguns bons já foram feitos e você só precisa implementá-los.
http://textangular.com/
Gráficos e outras coisas legais
As diretivas angulares são projetadas para fazer coisas como criar componentes de gráfico reutilizáveis. Eles não são totalmente diferentes dos Widgets Wordpress. Muitos deles já foram desenvolvidos e podem ser inseridos em seu projeto Angular.
http://www.sitepoint.com/creating-charting-directives-using-angularjs-d3-js/
Quanto ao Ember, não sei muito sobre ele, portanto não posso falar sobre suas características particulares.
fonte
Uma sugestão sobre o Backbone, se você decidir usá-lo, você deve ir para o Marionnete, pois é o Backbone, mas com uma estrutura arquitetônica melhor e mais opinativo (eu pessoalmente acho que o Backbone não estabelece nenhuma orientação e isso parece uma desvantagem em aplicativos grandes) .
Trabalhei com ele por alguns meses combinando diferentes js libs e não atrapalhou como outros frameworks e o pipeline de mensagem é uma maneira realmente boa de conectar componentes por meio do aplicativo, mas mantê-los separados.
Aqui você tem uma ótima palestra que me fez decidir por isso: https://www.youtube.com/watch?v=qWr7x9wk6_c
E aqui você tem um protótipo de demonstração que também possui o elemento arrastar e soltar mais outras bibliotecas js conectadas. Adoraria saber o que você pensa sobre meu código, já que tenho 1,5 anos trabalhando em desenvolvimento web ... ainda sou um novato: https://github.com/Drasky-Vanderhoff/marionette-demo/
Sobre o Knockout, é muito bom se você quiser interagir com o conteúdo que já possui e não vai se conectar constantemente com o back-end. Trabalhei com ele por 6 meses e acabei precisando usar várias outras libs js para roteamento; Além disso, acabo repetindo muitas das estruturas que o Backbone e outros JS Frameworks acabam tendo. O que direi é que não vai atrapalhar de jeito nenhum e ser mais uma ferramenta do que um constrangimento. Além disso, isso foi há quase um ano, então algumas coisas mudaram.
Uma coisa, se você encontrar Knockback (Knockout + Backbone) ... evite, a documentação não é tão boa quanto deveria e vai demorar muito mais tempo para aprendê-la. Se você quiser ir em frente, faça primeiro um protótipo rápido para ver se é o que você deseja.
fonte