作者dream1124 (全新开始)
看板Soft_Job
标题Re: [讨论] 请大家聊聊 JavaScript的缺陷
时间Thu Nov 5 02:59:31 2020
1F：推 laputaflutin: 同意楼上，不过看到这次美国大选很多新闻网都拿11/04 21:02
2F：→ laputaflutin: svelte来写，感觉蛮有趣的，应该会拿来试试看11/04 21:03
禁不住好奇心的我终究还是去看一下 Svelte，
原来它是个反 React、反 Vue、反前端在浏览器动态解析样板的框架兼开发工具。
它让你在开发时期能够先以 js 程式码定义资料，
或是用它提供给你的特殊语法指示产生 html、css 等内容的逻辑，
接着它会依据你写的 js 和特殊语法帮你产生 html 等资源并填充内容，
最後你再发布这些资源到使用者的浏览器上……
咦…… 等等，这概念怎麽似曾相识啊？
这不就是古早 jsp、asp、php 时代後端吐网页给浏览器的工作模式吗？
前端从 jQuery 之後的 prototype、backbone 时代开始渐渐与後端分家，
衍生出 angular、react、vue 等函式库，後来为了同时解决 SPA 和 SEO 的问题
又发展出令後端会心一笑的「server-side rendering」术语。
现在前端竟有人「标新立异」地发展出与 jsp、asp、php 概念相近的 Svelte。
真是太讽刺了前端，你离开你後端绕了一大圈，
最後写出来的程式竟然是你不想写的，後端的程式，
所以说呢，人心最後终究是要回到故乡来的，
这个四千里长江的尽头上海，或许正是你的极限也说不定。
Welcome home～ <3
小弟愚鲁，除了 CDN 那边的运作模式可能会有些不同，
以及後端伺服器执行时不用为样板暖机以外，
实在不太懂这东西在用起来跟传统後端样板科技有多大不同啊～
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 61.231.183.84 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1604516373.A.39D.html
3F：推 laputaflutin: 这就跟我刚看到elm 有种我跑回去写 GUI 的感觉一样 11/05 04:39
4F：推 superpai: 一切只为了人类等那几秒reload 11/05 05:56
5F：→ superpai: 应该是说不想等 11/05 05:56
6F：→ jobintan: SSR正是解决SPA加载时空白时间，先有个东西给人看，免得 11/05 07:13
7F：→ jobintan: 有些人等着等着，耐心都等没了，直接索性离开呢。 11/05 07:14
8F：推 newhandfun: 笑了，很幽默 11/05 09:54
9F：推 chatnoir: 觉得没什麽不同就回去写template语言罗 11/05 11:00
10F：推 mercurycgt68: 我主管都说给使用者看的就叫前端 给管理者看的页面 11/05 13:00
11F：→ mercurycgt68: 都叫後端 所以 svelte 还是前端无误 11/05 13:00
12F：→ OhGNM: 觉得你好像有点误会, 推荐你可以看该作者的演讲https://you 11/05 13:19
13F：→ OhGNM: tu.be/AdNJ3fydeao 11/05 13:19
他真的很屌，呢呢喃喃在它的语法和它生成的程式码之间来来去去，
却是少数让我花了几分钟仍看不出有什麽重大突破的框架。
他就是想进一步改善前端开发者在意的几项议题，例如让前端开发时再少写一点程式码，
然後输出的程式码更简短，
这样要是你前端软体规模够大，那或许真能为团队带来足够的好处，但代价是什麽？
叫前端再多学一种语言 ─ svelte script 以及他开发出来的工具！
你要同时用 html、css、javascript（或是 ts？）、svelte 语法开发前端模组，
然後再去熟悉他开发的工具了。
呃… 你不累吗？ 不觉得更杂乱了吗？ 逐行除错的工具要去哪里找？ 怎麽设定？
调整或整合建置与打包工具不麻烦吗？ 抽象泄漏的时候不可怕吗？
至於一人专案又无营利什麽的就更不用多提了。
你要用这种方式开发 SPA 为何不乾脆直接去用 GWT、flutter ，或是 qt 转 wasm 那样
单一语言，单一 programming mode，单一 api 开发前端的东西啊？
这类工具以後就直接生成 wasm 了，到时你根本就不必理会框架生成什麽 js 程式码，
交给厂商根据你写的程式码去最佳化就好。
效能差就骂原厂，真要简单又效能佳就再回头写 js，
不像 svelte 竟然还拿他生成的东西出来当卖点讲。
在我看他这方案赢不过目前主流 SPA 函式库加上程式码拆分再延迟载入的组合，
或是其他通用语言图形介面转 wasm，甚至是妥善模组化的後端样板。
他就是在标新立异，为不一样而不一样，把事情弄得更复杂罢了。
14F：推 Jokering5566: seo问题呢？ 11/05 13:52
15F：推 superpai: 你的累跟麻烦是别人的乐趣欸 11/05 15:33
玩啊～ 又没说你不能找新玩具
我只是觉得开发者终究还是要让精力尽可能投注在自己要开发的程式，
而不是用来开发自己要开发的程式之程式。
16F：嘘 dojay: 只能说你不了解前端，现代前端框架都是想要提供 reactive 11/05 16:35
17F：→ dojay: 机制还有元件化，这两样东西已经被证明对开发效率有极大的 11/05 16:35
18F：→ dojay: 帮助，如何拥有这两者的同时也贴近只用JS 的效能，才是各 11/05 16:35
19F：→ dojay: 个框架努力的目标，是你连目标都没搞清楚，就别秀下限了。 11/05 16:35
我若不懂他的限制与他的目标，那怎麽写得出回给 OhGNM 的第二段内容？
然而开发者终究还是要让精力尽可能投注在自己要开发的程式，
而不是用来开发自己要开发的程式之程式。
你讲的概念又是个已知用火的好例子，早在 react、vue 都没问世之前，
其他通用语言图形介面函式库早就是一个一个元件，有介面内容随状态更新的设计了，
现在就只差转成 wasm 让浏览器可以读罢了。
你若要那样四种语言，模组码与生成码来回搞，那还真的不如去写单一语言加 wasm。
看来我可能不懂框架的目标，而你却是不懂工作的目标啊？
最後附带一提，他拿了一个 React 的 function 元件 todo list 在讲 filter 的繁琐，
然後说了自己提供的简化语法。
但我转头一想，他为什麽要让母元件过滤子元件的状态再去变更 dom tree 结构，
而不是让子元件自己管自己的状态，
然後根据母元件给的参数和自己的状态判断要不要 display:none 就好？
用它的 filter 语法可以缩短你 filter 的程式码，但我连 filter 都不用欸～
20F：→ stopcrying: 一堆 local state 和 mutation 会让你的元件很难 scal 11/05 18:48
21F：→ stopcrying: e 吧 11/05 18:48
22F：推 superpai: 其实就是所谓不如单一语言是你自己的偏好而已，很多人就 11/05 19:29
23F：→ superpai: 是喜欢多个领域专用的语言然後凑在一起。 11/05 19:29
24F：→ ku399999: ...你的子原件还是要做loop或filter才有办法显示 11/05 21:36
25F：→ ku399999: 喔对不起我搞错体的意思了 11/05 21:38
26F：→ ku399999: display none喔 你4不4很久没写前端了 11/05 21:38
27F：推 strlen: 楼上刚好反证原生JS没效率又难用 又一个帮忙证实JS就是垃 11/05 23:12
28F：→ strlen: 圾的证词 11/05 23:12
29F：→ strlen: 你看看 要是JS原本就好棒棒 会需要那些一拖拉库的低能函式 11/05 23:13
30F：→ strlen: 库和框架？所有语言里就JS最多「补强」 笑死 11/05 23:13
31F：→ ku399999: 现在的js并不慢耶，慢的是dom api。我是不会说他多好用 11/06 00:45
32F：→ ku399999: ，但就算其他语言你这样用确定code review不会被定在墙 11/06 00:45
33F：→ ku399999: 上吗？ 11/06 00:45
34F：→ ku399999: 我只是想说，把这个跟jsp比表示他根本没搞懂吧，批的很 11/06 00:47
35F：→ ku399999: 奇怪 11/06 00:47
36F：→ ku399999: 有时候人生就是这样 语言缺陷多还是很多人用 要学会习惯 11/06 00:50
37F：→ Schelfaniel: 之前有想过要用 svelte，但总觉得不如用 Vue 11/06 10:49
38F：→ ku399999: 公司产品还是不要乱冒险...side project可以用 11/06 14:22
40F：→ locklose: 自己生成画面与互动元件 11/06 16:14
42F：推 Saaski: 完全说出我对 SSR 的心声。如果说为了 SEO 还勉勉强强可以 11/06 20:47
43F：→ Saaski: 理解，为了不想看到那一两秒不到的 loading 画面就绕这麽 11/06 20:47
44F：→ Saaski: 一大圈实在是…… 11/06 20:47
45F：→ Saaski: 而且实际上真正的等待时间也没少啊，一个暮四朝三的概念 11/06 20:48
就是为了 SEO 啦！ 但这点也别怪前端，依我看这其实是 Google 的问题。
Google 早在发展支援 SPA 的爬虫技术之前就应该先提供一种 API 给前端，
让前端能够先快速产生要给搜寻引擎索引的内容，
然後再透过那个 API 通知 Google 它已呈现想给它索引的东西，
接着再产生要给使用者看的完整网页。
这样前端就不必非得在伺服器端产生页面内容才敢送去客户端。
为什麽有 sitemap 给搜寻引擎看，却不愿在 SPA 的时代提供这种 API 实在很奇怪。
46F：推 wulouise: 因为这样就会被伪装资料啊....要看当然要看真的 11/07 08:55
就算提供 API 也不代表爬虫只能解析使用者呼叫 API 之前产生的文件内容啊！
Google 可以抽验网站的内容，看看呼叫 API 前後的资讯是否相似以防欺骗嘛～
问题是若没有这种 API，那前端开发者怎麽知道爬虫能不能等到他呈现好网页的内容？
於是把原本在前端跑的程式放去後端的奇葩 SSR 不就势在必行了？
※ 编辑: dream1124 (118.160.95.12 台湾), 11/07/2020 10:03:13
47F：→ ku399999: dynamic rendering？ 11/07 21:25
48F：→ ku399999: google最新版的效能指标+效能会影响SEO 最後还是要做SSR 11/07 21:27
49F：嘘 electgpro: 论点完全没沾到 reactive 且看起来完全不懂 FP 带来的 11/08 02:01
50F：→ electgpro: 好处。建议你还是先去学懂了再来批。 11/08 02:03
51F：→ electgpro: "怎麽写得出回给 OhGNM" 问题是你没有回到点耶 11/08 02:05