Open tiye opened 11 years ago
我能明确的一个想法是, 希望写代码, 想做界面时能很容易就完成 因为代码是世界上同时很多人在写, 常用模块一般大家都已经实现过了 当我们设计一个良好的模块化方案, 其实编程真的不应该很麻烦 在看别人用 PhotoShop 或者其他工具做出精彩的界面时, 我在想, 代码能进行更强大的抽象, 为什么我不能用代码直接做这样的界面出来? 这是我现在对于编程最大的期望, 也是我最初理解的编程
上边说的主要就是图形界面, 还有模块化, 事情的中心就在浏览器上 平台的作用, 就是屏蔽底层的复杂性, 让上层的人能更简便地做出软件 动态语言是屏蔽复杂性的一种方式, CSS, HTML 也同样是 但浏览器问题在于要兼顾大量用户, 并且掌握在大公司的手里 玩代码的人想要各种新功能, 可用户比如尾大不掉的 IE8 让人无法如愿
Node 一个有点是小的核心, 接受大量的模块, 实现多种多样的功能 浏览器呢, 可以写插件扩展已有的标签么? 可以增加必要的 CSS 么? 还有 JS 语言的绑定和 JS 的模块化, 都是好多年无法解决的问题 做产品的人们会想各种方案用 JS CSS 做 Hack, 可总是进展缓慢 渐渐到浏览器失去信心的时候, 就开始想想好的一个平台是怎样的
界面的布局, 主要是一标签和另一个或多个标签间的关系 一个标签容纳另一个标点, 要确定一对固定的点, 还有相对父元素边界 超出边界, 滚动条就是必须的. 而且边框和滚动条不应占用空间 文本在网页中是流式布局的, 但不管怎样, 文本从来都存在屏幕这个边界 边界固定之后, 就不允许每个标签都能自由变换长宽了重新布局了
用点之后, 内容的变换就方便了, 而不用借助边距一类参数 但对于流式的文本来说, padding margin 还是有用 其次父元素参照点的选取上, 就该有更多语义化的选择方案 比如 center top-center top(10)-left(20), 或者之类的 还有就是使用网格布局, 允许标签选取一个网格的位置再去参照点
padding margin
center top-center top(10)-left(20)
一个标签包含多个标签时, 子标签通过栈来处理层叠关系 界面当然是不重叠的更好. 但需要时应该比 z-index 更好管理
z-index
HTML 缺失的功能体现在模版引擎里, 主要是简化的语法和抽象 CSS 选择器并不是让编程很轻松的事情, 也不是那么语义化 我的理解, CSS 应该是定义一个 class 名字, 在 HTML 上使用 而具体内容完全按照语义对应形成样式就好了
class
个人的看法是 HTML 上只应该负责布局和设置供代码操作的钩子 CSS 则对 HTML 的钩子和标签属性就像修改, 形成其骨架和功能 当然, 那就不能称 HTML 和 CSS 了, 而是进行了不同的分工 而后者的配置功能, 换做在 JS 代码里进行设定也就是可以 我觉得 CSS 选择器的功能更多应该暴露给 JS, 因为逻辑更灵活
只是说到底, 如果 JS 语言更强大, 其实一切在 JS 里操作也省事了 需要操作的其实是标签之间的相互关系, 位置和样式上的区别 我想当底层的逻辑能暴露给代码的话, 允许自行扩展就更容易 甚至像 Node 扩展函数一样扩展多个标签的样式, 封装成一个
exports
按 Node 中作域的理解, 需要是将一个 exports 暴露在模块之外 在 HTML 和 JS 分离的时候, 一个模块和 JS 的一个作用域是不对应的 这主要是个类比, 如果可行, 那么 require 一个图形的模块, 就能直接调用方法 那样的话, require 实际上就每次生成一个单独的 iframe 和作用域 如果有这类功能, 在 Node 中使用的一些方案其实就顺理成章
require
iframe
设想我们能自己撰写模块来扩展浏览器的功能了, 直接做组件 那么, 登录, 以及文件上传是非常常见非常普通的功能就应该有模块 而且设想和多的组件其实就应该是这样一个形式出现在代码中的 写简单的页面根本不该从写模块开始, 而仅仅应该是胶水
原本软件应该像是快速下载, 同时解释执行的样子, 加上更多模块的缓存 而浏览器端却是先有界面, 再不断对界面做各种各样的更改 是否这就是网页应用总是比 Flash 更快加载的原因呢..
我能明确的一个想法是, 希望写代码, 想做界面时能很容易就完成 因为代码是世界上同时很多人在写, 常用模块一般大家都已经实现过了 当我们设计一个良好的模块化方案, 其实编程真的不应该很麻烦 在看别人用 PhotoShop 或者其他工具做出精彩的界面时, 我在想, 代码能进行更强大的抽象, 为什么我不能用代码直接做这样的界面出来? 这是我现在对于编程最大的期望, 也是我最初理解的编程
浏览器
上边说的主要就是图形界面, 还有模块化, 事情的中心就在浏览器上 平台的作用, 就是屏蔽底层的复杂性, 让上层的人能更简便地做出软件 动态语言是屏蔽复杂性的一种方式, CSS, HTML 也同样是 但浏览器问题在于要兼顾大量用户, 并且掌握在大公司的手里 玩代码的人想要各种新功能, 可用户比如尾大不掉的 IE8 让人无法如愿
Node 一个有点是小的核心, 接受大量的模块, 实现多种多样的功能 浏览器呢, 可以写插件扩展已有的标签么? 可以增加必要的 CSS 么? 还有 JS 语言的绑定和 JS 的模块化, 都是好多年无法解决的问题 做产品的人们会想各种方案用 JS CSS 做 Hack, 可总是进展缓慢 渐渐到浏览器失去信心的时候, 就开始想想好的一个平台是怎样的
标签的关系
界面的布局, 主要是一标签和另一个或多个标签间的关系 一个标签容纳另一个标点, 要确定一对固定的点, 还有相对父元素边界 超出边界, 滚动条就是必须的. 而且边框和滚动条不应占用空间 文本在网页中是流式布局的, 但不管怎样, 文本从来都存在屏幕这个边界 边界固定之后, 就不允许每个标签都能自由变换长宽了重新布局了
用点之后, 内容的变换就方便了, 而不用借助边距一类参数 但对于流式的文本来说,
padding margin还是有用 其次父元素参照点的选取上, 就该有更多语义化的选择方案 比如center top-center top(10)-left(20), 或者之类的 还有就是使用网格布局, 允许标签选取一个网格的位置再去参照点一个标签包含多个标签时, 子标签通过栈来处理层叠关系 界面当然是不重叠的更好. 但需要时应该比
z-index更好管理标记语言
HTML 缺失的功能体现在模版引擎里, 主要是简化的语法和抽象 CSS 选择器并不是让编程很轻松的事情, 也不是那么语义化 我的理解, CSS 应该是定义一个
class名字, 在 HTML 上使用 而具体内容完全按照语义对应形成样式就好了个人的看法是 HTML 上只应该负责布局和设置供代码操作的钩子 CSS 则对 HTML 的钩子和标签属性就像修改, 形成其骨架和功能 当然, 那就不能称 HTML 和 CSS 了, 而是进行了不同的分工 而后者的配置功能, 换做在 JS 代码里进行设定也就是可以 我觉得 CSS 选择器的功能更多应该暴露给 JS, 因为逻辑更灵活
只是说到底, 如果 JS 语言更强大, 其实一切在 JS 里操作也省事了 需要操作的其实是标签之间的相互关系, 位置和样式上的区别 我想当底层的逻辑能暴露给代码的话, 允许自行扩展就更容易 甚至像 Node 扩展函数一样扩展多个标签的样式, 封装成一个
模块的
exports按 Node 中作域的理解, 需要是将一个
exports暴露在模块之外 在 HTML 和 JS 分离的时候, 一个模块和 JS 的一个作用域是不对应的 这主要是个类比, 如果可行, 那么require一个图形的模块, 就能直接调用方法 那样的话,require实际上就每次生成一个单独的iframe和作用域 如果有这类功能, 在 Node 中使用的一些方案其实就顺理成章登录功能, 以及文件上传
设想我们能自己撰写模块来扩展浏览器的功能了, 直接做组件 那么, 登录, 以及文件上传是非常常见非常普通的功能就应该有模块 而且设想和多的组件其实就应该是这样一个形式出现在代码中的 写简单的页面根本不该从写模块开始, 而仅仅应该是胶水
下载运行软件
原本软件应该像是快速下载, 同时解释执行的样子, 加上更多模块的缓存 而浏览器端却是先有界面, 再不断对界面做各种各样的更改 是否这就是网页应用总是比 Flash 更快加载的原因呢..