webix框架兼容javascript.HTML.CSS,应用比较灵活,应用框架时,配合后台webAPI,整个web项目里面,App文件夹保存前台的多语言文件,图片文件,webix原代码js.css,视图文件等,视图文件里面全是使用js文件编写页面布局与功能实现,文件开头使用define(["locale", "/app/views/shared/components.js"], function (_, com) {...页面代码段}来实现父页面对子页面的调用,包…

webix框架兼容javascript.HTML.CSS,应用比较灵活,应用框架时,配合后台webAPI,整个web项目里面,App文件夹保存前台的多语言文件,图片文件,webix原代码js.css,视图文件等,视图文件里面全是使用js文件编写页面布局与功能实现,文件开头使用define(["locale", "/app/views/shared/components.js"], function (_, com) {...页面代码段}来实现父页面对子页面的调用,包…

这篇是我参加QCon北京2014的演讲内容: 提纲: 企业应用在软件行业中占有很大的比重,而这类软件多数现在也都采用B/S的模式开发,在这个日新月异的时代,它们的前端开发技术找到了什么改进点呢? B/S企业软件前端开发模式大体上与桌面软件类似,都是偏重量级的,在前端可能会有较多的业务逻辑,这些业务逻辑如何被合理模块化,与界面分离,以便测试,成为这个领域的一个重要挑战.另一方面,由于企业应用的界面相对规整,偏重的是数据存取,没有太多花哨的东西,所以常见的界面控件也是可枚举的,如何让开发界面的工作能…

目   录 1.遇到的问题 2.目标 3.探讨 4.架构设想 5.流程 6.初步实现 7.存在问题 8.最后 遇到的问题 我在这个系列上篇文章 已经讲解并开始逐步应用模块化思想,不知大家还记不记得,题目:[PC网站前端架构探讨系列]结合公司网站首页,谈前端模块化开发与网站性能优化实践 .但是,仍然会存在下列问题: 问题1----模块内部脚本和页面联系密切  问题2----所有脚本文件集中放于一个目录,脚本目录不清晰,没有层次 当然还有其他很多问题,但就以上两大问题来说,会对后期代码维护带来不便!…

在前面的文章里我谈到了前后端分离的一些看法,这个看法是从宏观的角度来思考的,没有具体的落地实现,今天我将延续上篇文章的主题,从纯前端的架构设计角度谈谈前后端分离的一种具体实现方案,该方案和我原来设想有了很大的变化,但是核心思想没变,就是控制层是属于Web前端的. 在以前文章里我说道前后端分离的核心在于把mvc的控制层归为前端的一部分,原方案的构想在实际的生产开发里很难做到,我觉得核心还是控制层和视图层的技术异构性,这样后果使得系统改造牵涉面太大,导致在项目团队里,沟通.协调以及管理成本相对较高,…

前言 不知何时突然冒出“MEAN技术栈”这个新词,听起来很牛逼的样子,其实就是我们已经熟悉了的近两年在前端比较流行的技术,mongodb.express.angularjs.nodejs,由于这几项技术涵盖了从前端到后端再到数据库,可以用他们完整的开发一个web应用了,所以成了一个非常牛逼的组合,颇有当年LAMP的气势.前端要从切图仔迈向全栈的路上,这几门技术必须得有所涉猎.本系列文章利用自己虚构的一个小项目为例,对“使用MEAN技术栈开发web应用”做一个入门级的介绍.   AngularJs…

架构创作初衷 每当新开一个项目时,都会绞尽脑汁去考虑采用哪种框架:requirejs/seajs.jquery/zepto.backbone.easeUI/Bootstrap/AngularJS……,特别是团队合作的时候,不同的人熟悉不同的框架,最终都会经过一番头疼才能定下来,进入开发之后还会不断的质疑当初的选择.鉴于此,我想开发一个属于自己的框架,一方面把前端知识贯穿一下,另一方面用起来也顺手,免得又犯选择恐惧症.开发之初,我给框架的定位是: 1. 好用 组件直接采用$(容器).组件名{…},…

关于语义学 语义学是研究符号和意义之间的关系以及它们表示的内容.在语言学中,则主要是研究符号(例如单词,短语或者语音)在语言中所表达的意义.而在前端开发时,语义学则更多的关注HTML元素,属性以及它的值所表达的含义.而这些规范的语义可以帮助开发人员更好的理解网站上的信息.但是即使是以非常正式的形式来规范这些语义,程序员仍然会去修改这些语义. 各种HTML语义之间的区别 书写语义化的HTML是现代专业的前端开发基本原则之一.绝大部分的语义是和已经存在的内容或期盼的内容的本性息息相关的(例如:h1元…

序 我们在上面的文章中已经建立起来一个比较简单的 前端架构 虽然这个看上去很简陋. 不过毕竟也是思想的结晶. 从这一篇文章开始,我将陆续完善这一个前端架构.. 重新构思 上一篇我们把前端架构分为3个模块: 他们分别是 数据层,模板层,交互层... 这样情况下 ,确实会 比那种混杂在一起的 纯js页面 要更有结构化 更利于维护.. 这个也是借鉴了 MVC 模式的逻辑进行构建的.. 但是,在实践开发过程中.我发现,仅仅是这样的分层 在交互层这一块显然还是有点杂..在这一层 既要处理 数据逻辑 又要处…

前言: 以前的工作大部分都是,前端做页面 稍微写几个js效果就算是 有复杂的效果 也没有涉及到 需要去调用后端数据的层面.总体来说,以前的页面逻辑会相对简单后端会做更多的事. 而现在,这些任务都抛给前端来做了..  前端的业务逻辑变得很复杂 有的时候甚至 比后端的更复杂.(当然这个也跟写接口的人水平有关...) 在这样的背景下面,如果还是以前那套 页面里面写js 或者哪里有效果写哪里的话.无论是实现,还是后面的维护都是一个很大的问题.. 所以,我觉得富客户端web应用,很有必要组建一个自己的前端…