WEB前端开发的技术选型

　　一、目标1。服务端开发。
　　没有服务端这一层抽象，没有了服务端路由和服务端中间件技术，前端开发的成果沦为在web服务器上托管一个静态html资源文件夹，毫无疑问是不可接受的！让前端程序员丧失了解决各种复杂需求的可能性。2。以多页为基础。
　　架构必须是多页的，单页是数量为1的多页！企图违背W3C关于网站是一系列网页的集合，网页之间通过超链接形成网状导航结构的基本抽象，都是绝对不可接受的。SPA在解决某些问题时非常有价值，但是只能是作为一个局部技术存在。3。包容各种客户端技术。
　　不同的网页当然可以使用不同的技术，一个网站内的页面应该是弱耦合的，否则难以实现前端技术的自然演化。甚至，同一个页面内部都应该追求各种技术的可能性，比如webcomponent，或者在一个Html中引入react、vue、jquery等多种技术编写的组件。二、技术原则1。自由。
　　使用函数库，使用工具，而不是使用框架。
　　使用函数库：自己写代码调用库函数是随心随意的，而不是让框架调用自己写的代码。自己调用代码是主动的，想怎么调就怎么调，不想调用就不调用。让框架调用，就得遵守框架的约束，框架的规范其实也是一种束缚，让代码依赖框架。
　　使用工具：模板代码可以使用工具来完成，而不应该固化嵌入在框架中。作为工具生成的东西是直接表达在源代码中的，可以直观理解，还可以根据需要修改，而用了框架之后就成了黑魔法，不好理解还丧失了灵活性。
　　很多时候，框架往往也是可以作为函数库和工具来使用。2。自主。
　　除了基础性技术（底层或应用层）有技术门槛，上层的应用类的技术，往往不过是对最佳实践的抽象，要审慎评估在具体项目中的价值，能不用就不用，保持自己技术独立性和自主性，长远来说是有收益的。
　　底层基础性技术，比如nodejs、pnmp、typescript，以及建立在这些技术之上的资源和生态，是难以取代的。这些是我们应该去依赖的技术。
　　应用基础性技术，比如jquery、esbuild、gulp、rollup、koa、vue、svelte，也不是一般的技术公司能能自己实现的，这些技术也是我们可以去依赖的。虽然这些技术也在不断地迭代，比如vue、react、anglar、svelte之间的竞争，但是这样的技术只能选型，作为一个通常的软件公司是不可能去做这些技术的。
　　ui界面库大家所熟知的elementui、antui等等，打包方面的webpack、vite、前端框架的next、nuxt、sveltekit、后端的express、egg、nestjs等，对具体的项目，具体的页面来说，直接用html、css、js来堆代码，未必是一个糟糕的选择。自己堆出来的代码，只要具备书写高质量代码的能力，自然会形成自己的积累，自然会产生最符合自己需求的无形的框架。仔细想想，webpack、vite中的支持HMR的开发服务器能有多难实现，如果不实现，只要build是自动的，开发调试的需要基本也就是一个浏览器的刷新点击了。
　　这一类应用层的技术可以选择primevue、quasar、vite、nuxt在使用中研究学习借鉴，最终逐步形成自己的技术方案。3。简单。
　　最好的架构是不用架构、最好的算法是不用算法、最好的技术是不用技术，不过度设计，尽可能用最基础的技术完成代码的开发，架构、算法和各种建立在基础技术之上的技术都会带来复杂性，带来学习成本和维护负担。对于web开发，css、html、js以及建立在这三个之上基础性技术才是值得认真学习的技术，应用层面的技术学习无助于提升程序开发的核心能力。三、选型1。底层技术路线：nodejs、pnpm、typescript、sass。
　　Web前端开发就是UI（用户交互界面）的开发，开发成果为通过浏览器可以请求的页面，所以从本质上来开发成果就是一个供浏览器访问的WebServer。即使是一个静态文件夹放到nginx中，本质上也是一个Webserver。
　　前后端分离的核心是明确区分了前后端的职责，后端是提供api的webserver，前端是提供ui的webserver。
　　对于简单应用，ui就是一个或几个静态html页面，对于复杂应用，通过服务端路由动态产生页面响应的抽象层就是解决问题的一个关键手段。
　　技术线路的选择，核心就是选择语言，不同语言形成了各自的开发生态，程序员的技术积累也是在某种语言上承载的，本质上，语言是人类思维的外壳。
　　显然js（nodejs）、php、c（aspx）、java、go等语言都可以用来开发webserver应用。就目前的主流技术，基于nodejs是一个自然而然的选择。nodejs
　　deno：尚未成为主流，带来的安全性沙箱、ES模块、TypeScript在nodejs下都有成熟的解决方案。安全更应该用docker不该由语言来考虑，typescript通过构建即可，ES模块在nodejs中有支持的兼容性设计。pnpm
　　选择了nodejs，就必然地要选择一个包管理工具，就目前来说，pnpm是优选。
　　npm：扁平化的结构，存在重复依赖、幽灵依赖的问题。
　　yarn：扁平化的结构，压缩包仅解决了文件数量和空间占用问题。typescript
　　类型化是一个强大的生产力工具，结合IDE的智能提示，减少的开发员的查文档和记忆的负担。sass
　　less之类的份额越来越少了。2。工具：vite，或者gulprollupliveserver，或者gulprollupkoavite
　　对于没有服务端路由的需求，那么vite是最简明的一个傻瓜化的解决方案。
　　webpack、parcle：傻瓜化的工具，不灵活，感觉只适用于单页或单体应用，不太遵循网站是一些网页的集合这个基本抽象，vite应该是方向和趋势，gulprollupliveserver
　　对于没有服务端路由的需求，除了，vite，另一个选择就是：gulprollupliveserver。
　　gulp和roolup是非常基础的工具，大概类比于C的compile和make。grunt、browerify：逐步成为古董了。顺便说一下，对于生产的打包，vite使用的就是rollup。webpack和vite等自带热更新的开发服务器，所以使用gulp、rollup这样的基础工具时，需要借助于liveserver这样的web开发服务器。gulprollupkoa
　　对于需要服务端抽象层的需求，gulprollupkoa是一个比较底层的方案。
　　构建目标是基于服务端页面的前端Web应用，开发时构建debug版，发布时构建release版，debug启动时在koa服务器中叠加类似vite的HMR功能（事实上，vite最初的1。0版本中就是使用了koa）。虽然koa之上的egg对TypeScript不太友好，但应该和koa本身没有什么关系。
　　expess、nestjs、egg：和koa相比express太重了，更不用说建立在express之上的nestjs，以及建立在koa之上的egg。这些框架的目标是api和ui通吃的web框架，涵盖了后端业务层的开发目标，不符合前后端开发定位中仅仅服务于ui的目标。
　　nextjs、nuxtjs、sveltekit等，不符合包容各种客户端技术的目标，这三个框架分别和react、vue和svelte深度耦合，框架的可扩展性有限。3。框架：vue3或者svelte
　　如雷贯耳的react、vue和angular这样的框架，引领了web前端好几年了，逐渐暴露的缺点是封装太重了：和w3c标准不太相容，代码的直观表达性太差，学习成本高，把前端越弄越复杂。
　　根据现在的前端技术生态，先选择vue，逐步过渡到svelte。
　　angular的份额已经显示出疲态，为什么不选择react，而选择vue呢？我的非常另类的理由是vue更像svelte！vue3学习曲线比react要平缓，至于其他的技术比较，应该是各有优劣，而且技术越来越趋同。4。UI库：bootstrap
　　ui组件库，选择实在是太多了，基本上每家有点名气的互联网大厂都会开源一个出来。不论选择哪个库，都存在需要对其修改以满足项目需求的问题，所以，最好的选择是不选择整套的界面组件库，而是基于开放的css框架bootstrap，逐步编写和积累自己的UI库，对于复杂的表格组件、树控件组件等等，单独选型。
　　在自己做基础的UI组件时，有两个可以用来分析学习的组件库：primevue，体量适中、是专做组件库的、组件功能齐全、还有一点样式和功能分离的独特设计。quasar是属于巨无霸型的前端组件库，可以拿来研究借鉴，学习解决各种领域的前端问题。