#front-end programming

As web development continues to evolve, mastering the right front-end programming languages is crucial for staying ahead in the industry. Whether you’re a beginner or an experienced developer, learning the most in-demand front-end languages can help you create dynamic, user-friendly, and high-performing websites. In this guide, we’ll explore the top front-end programming languages you should…

What is Front-End Programming and what is it used for?

With the advent of the Internet in human life, various digital products with this technology have opened their way to our world. One of these digital products is websites. Today, most people are well acquainted with the sites and have complete information about their performance. These products and tools have made our lives easier in the first place. Many things like information, online shopping,…

As a Front End Developer, You’ll be Responsible and How to Create a Shopify Application?

As a front-end developer, I understand how challenging it can be to make the shift from front-end development to app development. App development needs a unique set of skills, not to mention the numerous moving pieces and technologies that must be considered throughout the process. However, this does not rule out the potential of it happening. My experience as a front-end developer migrating to…

前端开发正变得越来越复杂，随着软件和应用逐渐Web化，可以想见以后前端开发将会成为一个独立的部门，它将拥有现在软件开发部门所拥有的全套人员，如架构师、系统分析员、开发工程师和测试人员等等。

我blog上有一位朋友留言询问我如何定义“前端架构师”这样一个职位。虽然我没做过专职的前端开发，但一直都在参与相关的工作，甚至还曾经面试过“前端架构师”这个职位。因此结合我的个人经验，我理想中的前端架构师，应该是如下这个样子的：

职责：

提升网站的前端性能，保证前端应用具有跨浏览器和跨平台兼容性及可访问性

保证前端团队的编码质量，提升其工作效率

创建并完善内部所使用的前端工具和框架

定义与后端工程师合作的边界、标准化与后端程序的接口

技能：

精通前端开发技术和Web标准

至少精通一门后端程序语言，如PHP、Ruby、Python或Java等等

精通面向对象和各种设计模式

理解Web如何工作，如HTTP协议、Apache或Nginx等等

熟练使用各种相关的工具，如Subversion、Unix/Linux shell、VI或Emacs等等

了解交互设计的基本知识

沟通能力强，能够领导团队共同进步

我分别解释一下。

首先说职责。其中前两条应该算是架构师的一个基本职责了，无须赘述；第三条“工具和框架”很重要，有了好的工具和框架，网站的设计规范才能更顺利的得以实施，这点在以前的两篇文章中谈到过（说说互联网公司内设计师的分工和为什么网页设计不应强调分工1、2）；第四条“边界和接口”实际上以前也谈到过，这个意思就是说，后端程序只给数据，所有的页面逻辑和展现都交给前端来做。现在许多新兴的Javascript框架（如JavascriptMVC和SproutCore）都号称可以脱离后端程序、直接靠test fixtures就能独立运行，我觉得这就是对我这个观点的最好证明。

接下来说技能。技能确实没什么好说的，大部分都是一个前端开发工程师所应具备的技能。其中第二条对后端语言的掌握和第三条对设计模式的理解，实际上是相当一部分前端工程师所欠缺的（我就不懂设计模式），因此特别加上。

最后要说的是，各个团队需求不同，对工程师的要求也就不同。如果你不同意上文中的某些地方，可以留言说说你遇到的情况。

Y.Jiajia @ 2010-03-09 00:16:35 +0800:

恩，都是很基本的要求。我觉得还有一点是比较重要的，不仅需要定义与Server端工程师的接口与合作，同时还要与设计师有良好的沟通（非交互）与合作。因为如果前端工程师是企业价值的体现，那么设计师就是企业形象的代表（第一印象很重要）。

zszen @ 2010-03-09 07:14:06 +0800:

每次和后台接口, 我都会写一份doc文档 注明详细的功能, 命名, 参数来去传递, 传递方式, 特殊情况....

好累

ABDVL @ 2010-03-09 16:33:52 +0800:

职责的前两项是技能的话后两项就算是管理吧。各个WD部门都在“前端工具和框架”，“与后端工程师合作的边界”，"标准化与后端程序的接口".做着闭门造车的努力。 很少看到有谁来分享自己的“最佳实践”。 Sign....... PS.刚还看到一堆评论来着,转眼就没了.....

丁宇 @ 2010-03-09 17:18:38 +0800:

@zszen 你的文档是怎么写的？可否拿出来分享？

@ABDVL 1）职责的四项都是职责，当然管理也是一种职责 [emoticon:clin_oeil] ；2）是否闭门造车要看架构师或者管理者的眼界了，至少我们的项目组会仔细评估已有框架，并打算将自己的框架开源（如果最终决定自己做的话）； 3）有人发垃圾留言，被我拉黑名单了，话说LT的毛毛就是好用啊，哈哈。

望飞 @ 2010-03-12 05:29:53 +0800:

[emoticon:mdr]

JOY @ 2010-03-19 02:37:38 +0800:

恩最近对这个也有些迷茫

Mike @ 2012-06-07 01:19:46 +0800:

LZ 你觉得sencha touch 这个框架怎么样？ 谢谢 :)

丁宇 @ 2012-06-08 09:37:27 +0800:

Cappuccino

Cappuccino是一个非常别致的Javascript框架，它由一群前Apple工程师开发，力图在Web上通过Javascript来重写Objective-C语言，他们把这个语言称为Objective-J。这样原有的Cocoa程序员就可以继续使用他们熟悉的语法来开发Web应用程序，Cappuccino内建的解析器将在浏览器端负责解析。

我不得不说这个想法很疯狂，和Bindows、Qooxdoo这些框架比起来，Cappuccino走得相当的远。不过这群天才做得不错！从官方文档来看，Cappuccino已经逐渐成形：兼容所有主流浏览器（包括该死的IE 6）、有知名的演示站点280 Slides、有Cocoa那丰富的资源和完善的文档支撑、控件库漂亮且齐全，它甚至有一个名为“Atlas”的可视化IDE（这个一会儿详细说）。

我前一阵子花了不少时间研究Cappuccino和SproutCore，总的感觉是这两个框架有很多好玩的东西，表面看起来也很是惊艳，可小问题很多，离实用还有一段距离。

回过头来说几句Atlas，这是个很强悍的可视化IDE，它完全用Cappuccino构建，包含了代码编辑器和界面编辑器两个部分－听起来很像XCode和Interface Builder的组合，对吧？实际也是如此，它的界面编辑器简直就是Interface Builder在浏览器上的翻版！而且从视频来看，还保留了Interface Builder的一些界面特效。

应该说他们能做到这步非常不容易，毕竟浏览器的能力在那儿摆着呢。可是我搞不懂Atlas中界面编辑器的意义何在，因为愿意使用Cappuccino的几乎肯定是Objective-C程序员，而目前Objective-C程序员必定用的是Mac，他们完全可以使用Interface Builder，然后用Cappuccino提供的nib2cib把Interface Builder界面文件转换为Cappuccino模板。既然如此谁还愿意用浏览器上的编辑器呢？

Atlas本月13号发布开发者预览版，具体有何独到之处，让我们拭目以待吧。

Mockingbird

最近冒出了不少基于浏览器的原型制作工具，比如Lovely Chart和Balsamiq Mockups，这两个都是用Flash做的，Mockingbird是第一个也是目前唯一的一个用JS做的工具。我曾和@soulhacker在Twitter上讨论过制作一个Web版的OmniGraffle克隆，在技术上遇到的问题就是，这东西必须得用Flash来做，否则辛辛苦苦写的JS很容易就被拿走了。因此我非常不解Mockingbird为什么选择用JS来做这事儿。

同Lovely Chart和Balsamiq Mockups比起来，Mockingbird在功能上并没有什么特别之处，基本上可以说它有的功能别的工具也都有，但，除了以下两个：

链接

用鼠标把界面左面pages中的页面图标拖到编辑区的某个元素上，就代表这个元素将会链接到这个页面。这不仅可以生成链接，更重要的是，通过这个功能你可以让你的原型具备交互能力！

分享

原型图做好了以后，可以按右上角的Share按钮，Mockingbird会生成一个链接地址，把这个地址发给同事，就可以直接看到效果了。这功能其实挺方便的，不用再把原型图上传到服务器上了。

-----下面帮朋友发条广告---------

注重独立的生活观念，关注服装、影像、时尚，以轻松的视角体察城市生活 www.ochosto.com

liupeng @ 2009-11-11 00:13:02 +0800:

[emoticon:eye_up] 你总能发现一些新鲜好玩的玩意...呵呵，这个框架还没见过，我进去好好看看，不过他的IDE是不是只有MAC版的？

taine @ 2009-11-11 00:44:56 +0800:

本周的upa上海您去么？

丁宇 @ 2009-11-11 00:52:27 +0800:

@taine 好久不见。我去，见 http://dingyu.me/blog/posts/view/user-friendly-2009

一根弦 @ 2009-11-23 18:58:16 +0800:

不过MS不能直接保存到本地 [emoticon:zzz]

Y.Jiajia @ 2009-12-21 20:35:52 +0800:

有人写了一篇非常详尽且图文并茂的博客，介绍了25个常见的IE6的bug及其解决方法。如果你还在IE6的泥海中挣扎，不妨看看这篇"Ultimate IE6 Cheatsheet: How To Fix 25+ Internet Explorer 6 Bugs"。

JudahXIII @ 2009-10-06 03:50:30 +0800:

看完文章觉得文章第一句的方法确实其实是最好的。

The best strategy for dealing with Internet Explorer 6 is not to support it.

JudahXIII @ 2009-10-06 03:51:13 +0800:

读了老鱼的《前后端分离开发模式初体验》，暂时没有和他见面详聊的机会，所以就把读后感和想法写在这里。

08年春天我离开支付宝之前，曾和资金线的同事（主要是夏天）讨论过这种做法，即把view的部分完全交给前端开发，java程序员只需给出逻辑、接口、变量和数据。双方以接口文档为工作基础，用统一的开发平台（Eclipse＋SVN）来协调工作。另一方面，前端开发则不断地将Velocity/HTML封装成一个个的helpers，从而提高代码的可重用性，并以此降低编码难度（关于封装helpers这点，我曾在一次技术分享中谈过，不知老鱼是否还有印象）。我给这套方案起的名字是“开往中国的慢船”，在《为什么网页设计不应强调分工 2》一文中，我简要的介绍过。

从支付宝的情况来看，这种做法有比较大的可行性，既可以提高开发效率，又能把双方的工作边界定义的比较清楚。不过我当时即将离职，也就没有推动下去。这次看到老鱼的项目实践，很高兴。对于他说的那4点问题，我觉得：

不知道这个白板究竟“白”到了什么程度？做html的时候运行调试ajax了吗？有没有和开发约定好往返的数据内容及格式？

这个问题确实比较头疼，因为系分阶段根本不可能细化到变量名都定下来的程度。可能的解决办法有三个：一是考虑周全所有的流程分支，不能遗漏；二是管后台程序员要需要的数据，而不是被他的数据追着跑。比如这篇Creating Reusable Elements with requestAction所介绍的方法，就是让view在程序中占有了一个比较重要的位置（有点像web service）；三是逐渐把复杂的逻辑从view中提出来，返回到后台去，简言之让view变得更单纯一些。我觉得如果有必要的话，甚至可以引入“数据源”（datasource）的概念，把数据统一交到数据源中去处理，然后再让数据源和view交互。可以参考SproutCore的做法。

问题C和D基本上基本上可以靠沟通和协调解决。另外对于问题D，或许前端开发可以考虑转到Eclipse上来。

简言之，“开往中国的慢船”这套方案的核心之一，就是把view让前端开发来创建和管理，在项目的前期及中期，前端开发就已经利用test fixtures创建出可以正常运行、几近真实、但又只包含view的应用程序来。

注：“开往中国的慢船”来自于村上春树的同名作品。我发起的项目或技术方案都以村上的作品作为代号，个人习惯。

Rabelais @ 2009-08-24 18:35:57 +0800:

技术上我不太懂的，不过看了一下LZ说的，我感觉，是不是可以用游戏开发公司的“引擎+level design”来类比？

比如我们玩idsoftware的游戏，引擎是卡马克写的，但是前段的图形呈现，游戏内容，关卡设计，他是通通不管的，全部是其他家伙去写。

换言之，是说技术给了一个巨大的百宝箱，然后前端的人拣起所需要的东西进行搭建。

丁宇 @ 2009-08-24 20:44:56 +0800:

@Rabelais 对，可以这样理解。一言以蔽之，就是我反复提到的规范和框架。

mmtea @ 2009-08-26 03:04:39 +0800:

[emoticon:mdr] 没错，这个分离模式已经在不断落实，现在的瓶颈就是B这里。 B的第一点，基本上90%不错了。第二点，这需要一段时间的彼此磨合，慢慢形成标准，先有规则然后不断完善了。 第三点，这个目前不靠谱，跟开发者的能力有很大关系。 要实现你的梦想，丁宇，我们得多点人才行，哈哈。至少前后端比例正常点。

sunnyZ @ 2011-03-29 22:43:01 +0800:

[emoticon:eye_up] 正打算搞这个

ijse @ 2013-07-17 15:00:19 +0800:

写了一个新的jQuery插件，作用是根据你输入的文章标题，自动地将其中的英文字母和数字提取出来，然后生成一个slug。slug通常的作用是给blog文章一个漂亮的网址，比如你现在看到的这篇文章，它的网址是 http://dingyu.me/blog/posts/view/jquery-simpleslug-plugin，它的slug就是jquery-simpleslug-plugin。

这个插件在jQuery Plugin上的主页是http://plugins.jquery.com/project/jquery-simpleslug，觉得好用就投上一票 :D

演示

http://dingyu.me/blog/files/jquery-simpleslug-plugin/demo.html

用法

用法很简单，比如你blog编辑界面上用来输入slug的文本框的id为slug，用来输入文章标题的文本框的id为title，则只要如下一行代码即可：

$('input#slug').simpleslug({ source: 'input#title' });

source的意思就是生成slug的源文本框。除了这个参数以外，还支持以下两个参数

preview

你可以在input的旁边放一个id为preview的span，然后这样用preview：

$('input#slug').simpleslug({ source: 'input#title', preview: 'span#preview' });

这样插件会实时地把生成的slug显示出来，用处就是告诉用户这篇blog文章的完整的网址。比如你可以在span前面写上 http://dingyu.me/blog/posts/view/。

replacement

默认情况下单词或数字之间的间隔符是“-”。比如你输入“Hello world”，那么出来的slug就是“hello-world”。你可以改成你喜欢的，比如：

$('input#slug').simpleslug({ source: 'input#title', preview: 'span#preview', replacement: '_' });

和Wordpress集成

默认情况下，Wordpress会把文章标题整个作为slug，而有些人只想要其中的英文和数字。利用SimpleSlug的slugify()方法，这很容易：

修改 wp-includes/js/autosave.js

在文件开头加入如下代码：

function slugify(str, replacement) { //replace everything that is not a word character slug = str.replace(/[^0-9a-zA-Z]/g, replacement); //replace mutilple continous replacements slug = slug.replace(eval("/"+replacement+"{2,}/g"), replacement); //replace the beginning and ending replacement(s) slug = slug.replace(eval("/(^"+replacement+")|("+replacement+"$)/g"), ''); //convert the slug to lower case slug = slug.toLowerCase(); return slug; }

找到文件中的

jQuery("#title").val()

替换为

slugify(jQuery("#title").val(),'-')

保存文件，搞定！

下载

http://dingyu.me/blog/files/jquery-simpleslug-plugin/jquery.simpleslug.0.1.js

JudahXIII @ 2009-07-07 18:55:09 +0800:

可以问个题外话吗，为什么我在你这里永远没头像？有Gravatar的……

丁宇 @ 2009-07-08 07:27:39 +0800:

@JudahXIII 你的头像在其它地方可以正常显示嘛？别人的gravatar都可以正常显示的。

rose @ 2009-09-06 05:03:18 +0800:

这个在wordpress怎么用?

丁宇 @ 2009-09-07 06:25:17 +0800:

@rose 引入这个js文件，然后根据wp模板里面文本域的名称使用即可。

rose @ 2009-09-07 23:07:52 +0800:

不懂你说什么啊,能不能具体点吗

丁宇 @ 2009-09-08 01:36:24 +0800:

@rose 特意找了个wp用了一下。wp是自带这个功能的：编辑文章的时候，在标题下面有个“固定链接”就是。

rose @ 2009-09-09 05:33:35 +0800:

这个我知道,但我想自动运行,就不用次次手动改了

丁宇 @ 2009-09-09 19:45:17 +0800:

@rose 你说的“自动运行”是什么意思？在wp里你只要标题中有英文，wp就会自动的把字母提取出来放进slug，和我这个插件的效果一样。

rose @ 2009-09-11 07:33:19 +0800:

举个例子 : http://hutuworm.blogspot.com/2009/09/gmail-100.html 它的标题是"Gmail 停机 100 分钟的启示",但链接只保留了英文和数字,这是blogspot自动改的,不用手动改. wp若果用中文标题的的話,地址会生成一堆乱码的

丁宇 @ 2009-09-16 04:48:37 +0800:

周末帮你看一下，这几天早出晚归，累！

丁宇 @ 2009-09-20 22:01:56 +0800:

我从WordPress的官方站点上下载安装了一个中文版，当我输入中文标题后，WP会自动帮我生成一个中文地址，完全没问题。无论是在编辑文章的时候，还是发布以后访问起来都可以。

我下载的版本是2.8.4，字符集都是utf8。

rose @ 2009-10-01 09:08:46 +0800:

我知道可以,但是我只想slug里保留英文和数字 你的这个插件説"自动地将其中的英文字母和数字提取出来",似乎可以做到,但不知道怎么用到wp里

丁宇 @ 2009-10-10 02:09:24 +0800:

@rose 花了点时间研究了下，看我文章中的回复。

rose @ 2009-10-20 03:16:29 +0800:

改了,不起作用 jquery.simpleslug.0.1.js这个文件放在wp-includes/js/jquery/ 文件夹对吗?

丁宇 @ 2009-10-20 18:06:47 +0800: