整理文章后提交
This commit is contained in:
jimmy committed
1 parent
441dd0e18e
commit
473a07eba4
105 files changed
+1053
-678
No files matched your search
+17
-9
@@ -1,4 +1,13 @@
|
||||
## 使用环境
|
||||
---
|
||||
date: '2022-06-27T19:33:58+08:00'
|
||||
draft: false
|
||||
title: '如何在Vue3的Store中使用i18n'
|
||||
keywords: [ 'vue','vue3','i18n' ]
|
||||
tags: [ 'vue3','i18n' ]
|
||||
categories: [ 'skill' ]
|
||||
---
|
||||
|
||||
## 使用环境
|
||||
|
||||
> `Vue`的版本为：`3.2.36`，
|
||||
>
|
||||
@@ -8,8 +17,7 @@
|
||||
|
||||
几乎都最新版本了
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 问题复现
|
||||
|
||||
@@ -28,37 +36,37 @@ const { t, d, n, locale } = useI18n()
|
||||
|
||||
当在创建对应的i18n时，会先将对应的内容进行创建和导出：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
在这个文件中创建了i18n，并且对特定的配置项进行了指定，但是导出的这个i18n中有什么？
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
在配置的文件中已经存在了要使用的方法，也就是导出的：`t`,`d`,`n`等，要使用的方法也在这里面
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
在这个`global`中存在了对应的全局的方法，不需要通过i18n指定的方法进行引入执行，可以直接使用，所以这个就是要手动引入的内容
|
||||
|
||||
## 解决
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
使用这种方法问题得到解决，不过在尝试过程中，这种两种方式使用的i18n也是有区别的
|
||||
|
||||
在引入的过程中，因为方式不同，所以引入的方法其实也不是同一个
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
不过在对应的注释中也能略微看出二者的区别
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
使用方法引入的‘t’应当也有特有的内容，这里只进行列举，不继续深入探讨。
|
||||
+11
-16
@@ -1,11 +1,19 @@
|
||||
## 写在前面
|
||||
---
|
||||
date: '2022-08-26T12:33:58+08:00'
|
||||
draft: false
|
||||
title: 'JavaScript和Vue中实现表格(table)固定表头和首列【提供Vue和原生代码】'
|
||||
keywords: [ 'vue','vue3','JavaScript' ]
|
||||
tags: [ 'vue3','JavaScript' ]
|
||||
categories: [ 'skill' ]
|
||||
---
|
||||
|
||||
## 写在前面
|
||||
|
||||
本文主要介绍关于`JS`或`Vue`中如何进行表头，列固定，可以根据实际应用场景应用于`原生`，`Vue`，`移动端`，`小程序`中
|
||||
|
||||
实际效果展示：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
对于列的固定，`table`中有对应的方法，但是如果列和表头都要固定，只能通过其他方式实现，<span style="color:red;">如果您找到了更好的自身方法，还请斧正</span>
|
||||
|
||||
@@ -500,17 +508,4 @@ const Scroll = (event: Event) => {
|
||||
|
||||
|
||||
|
||||
`本文仅代表本人粗鄙的拙见，如果有疏忽和纰漏，还请大佬斧正`
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,91 @@
|
||||
---
|
||||
date: '2022-08-25T10:33:58+08:00'
|
||||
draft: false
|
||||
title: 'Vue3中的ref为何要用.value进行值的调用？'
|
||||
keywords: [ 'vue','vue3' ]
|
||||
tags: [ 'vue3' ]
|
||||
categories: [ 'skill' ]
|
||||
---
|
||||
|
||||
在`Vue2`中，所有的数据都通过一个Data进行统一的返回，并且在data中对某个组件要用的数据进行统一的管理，常见的使用形式是这样的：
|
||||
|
||||
```html
|
||||
<template>
|
||||
<div class="div">
|
||||
<todos :Obj="tos" :removeObj="removeObj"></todos>
|
||||
</div>
|
||||
</template>
|
||||
|
||||
<script>
|
||||
import search from '@/components/search'
|
||||
import todos from '@/components/todos'
|
||||
import all from '@/components/all'
|
||||
|
||||
export default {
|
||||
name: 'App',
|
||||
data () {
|
||||
return {
|
||||
tos: [
|
||||
{ id: '001', value: '第一个', done: true },
|
||||
{ id: '002', value: '第二个', done: true },
|
||||
{ id: '003', value: '第三个', done: false },
|
||||
{ id: '004', value: '第四个', done: true },
|
||||
],
|
||||
}
|
||||
},
|
||||
computed: { },
|
||||
components: {
|
||||
search, todos, all,
|
||||
},
|
||||
methods: {
|
||||
removeObj (obj) {
|
||||
console.log(obj.id)
|
||||
this.tos = this.tos.filter(item => item.id !== obj.id)
|
||||
console.log(this.tos)
|
||||
},
|
||||
},
|
||||
}
|
||||
</script>
|
||||
|
||||
<style scoped>
|
||||
// 样式
|
||||
</style>
|
||||
```
|
||||
|
||||
可以看出来这里定义的内容都在一个数组中进行，或者是一个函数，将要使用的数据返回出来，这里无论怎么进行操作处理，最终进行数据代理的时候得到的都是一个对象，Vue2中直接通过`defineProperty`进行处理，并绑定对应的监听事件进行响应式的处理。
|
||||
|
||||
而Vue3中，数据的定义可以是单独的，Vue可以让我们随时需要随时定义，这也就带来了另一个问题，我需要的一个数据可能不是对象
|
||||
|
||||
```js
|
||||
<script lang="ts" setup>
|
||||
|
||||
let str = ref('响应式字符串')
|
||||
let obj = reactive({
|
||||
name: '张三',
|
||||
age: 10,
|
||||
})
|
||||
|
||||
</script>
|
||||
```
|
||||
|
||||
如果要定义的数据不是对象，还需要代理会怎么样？
|
||||
|
||||
在Vue2中数据的定义都在对象中统一进行，也就不会出现这种情况，如果一定要代理一个单独的数据呢？
|
||||
|
||||
Vue2中的数据代理通过`defineProperty`进行实现，也就是说我们要让`defineProperty`代理一个普通的数据，而不是一个对象，在`defineProperty`的MDN的文档中是这样定义的：
|
||||
|
||||
> **`Object.defineProperty()`** 方法会直接在一个对象上定义一个新属性，或者修改一个对象的现有属性，并返回此对象。
|
||||
|
||||
通过这个可以明确看出，只能进行对象的代理，不能进行普通数据的代理，如果使用普通数据类型会直接报以下错误[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-p1Lm0OSJ-1661407967498)(Vue3中的ref为何要用.value进行值的调用？.assets/image-20220825094409254.png)]
|
||||
|
||||
在Vue3中数据代理可以使用单一数据了，并且也改进了数据代理的方式，使用的是`Peoxy`完成了数据代理，而MDN中对`Proxy`也进行了定义：
|
||||
|
||||
> **Proxy** 对象用于创建一个对象的代理，从而实现基本操作的拦截和自定义（如属性查找、赋值、枚举、函数调用等）。
|
||||
|
||||
可以看出，`Proxy`依然是为对象服务，而不是普通的内容，这样问题似乎就解决了
|
||||
|
||||
本操作的拦截和自定义（如属性查找、赋值、枚举、函数调用等）。
|
||||
|
||||
可以看出，`Proxy`依然是为对象服务，而不是普通的内容，这样问题似乎就解决了
|
||||
|
||||
> 即使是Vue3中使用的`Proxy`的代理方式也不能进行普通数据的代理，所以当调用`Ref`的时候其实仍然创建了一个`Proxy`对象，并且Vue帮你给这个对象了一个`value`属性，属性值就是你定义的内容，改变的时候监视的改变依然是通过`Proxy`的数据劫持来进行响应式的处理，而模板中使用的时候`Vue`会默认调用对应的`value`属性，从而完成模板中的内容的直接调用
|
||||
@@ -0,0 +1,377 @@
|
||||
---
|
||||
date: '2022-08-11T16:44:29+08:00'
|
||||
draft: false
|
||||
title: 'Vue3新属性 — css中使用v-bind（v-bind in css）'
|
||||
keywords: [ 'vue','vue3' ]
|
||||
tags: [ 'vue3' ]
|
||||
categories: [ 'skill' ]
|
||||
---
|
||||
|
||||
# Vue3新属性：CSS 中的 `v-bind()`
|
||||
|
||||
## 写在前面：
|
||||
|
||||
本文主要介绍Vue3中的新增的`v-bind()`的常用使用方式，主要包括在`css`,`less`,`scss`中的使用，可以参考官方文档查看：[Vue3官方文档](https://cn.vuejs.org/api/sfc-css-features.html#v-bind-in-css)，本文将主要通过一个demo中的使用来展示
|
||||
|
||||
## 实际使用：
|
||||
|
||||
先创建一个通过的页面结构，因为是结构是通用内容，所以这里在直接进行简单的定义
|
||||
|
||||
```html
|
||||
<div class="div">
|
||||
<div class="span">
|
||||
<div class="span_title">
|
||||
这是测试文字
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
```
|
||||
|
||||
- 在`css`中：
|
||||
|
||||
在`css`中主要通过直接进行绑定，主要包括几种使用方式（我自己编的名词）：`直接使用`、`拼接使用`、`对象调用`、`组合使用`【这是我想到的几种常见方式，如果有特殊需求，可以评论区沟通】
|
||||
|
||||
在JS中先对需要用的数据进行定义：
|
||||
|
||||
```js
|
||||
|
||||
// 进行拼接调用测试的数据
|
||||
let width = 400
|
||||
|
||||
// 直接调用的数据
|
||||
let div_height = '400px'
|
||||
let div_color = '#e89393'
|
||||
|
||||
// 对象调用的数据
|
||||
let span = {
|
||||
width: '200px',
|
||||
height: '200px',
|
||||
color: 'green',
|
||||
}
|
||||
|
||||
// 组合调用的数据
|
||||
let transition = 'cubic-bezier(0, 1.5, .6, 1)'
|
||||
```
|
||||
|
||||
然后这些数据直接在`css`中进行使用，使用`v-bind()`进行绑定
|
||||
|
||||
```css
|
||||
<style scoped lang="css">
|
||||
.div {
|
||||
/* 拼接使用 */
|
||||
width: v-bind(width + 'px');
|
||||
/* 直接使用 */
|
||||
height: v-bind(div_height);
|
||||
background: v-bind(div_color);
|
||||
}
|
||||
|
||||
.span {
|
||||
/* 对象调用 */
|
||||
width: v-bind('span.width');
|
||||
height: v-bind('span.height');
|
||||
background: v-bind('span.color');
|
||||
display: flex;
|
||||
justify-content: center;
|
||||
align-items: center;
|
||||
}
|
||||
|
||||
.span_title {
|
||||
width: 100px;
|
||||
height: 100px;
|
||||
background: #000;
|
||||
color: white;
|
||||
/* 组合使用 */
|
||||
transition: all .9s v-bind(transition);
|
||||
}
|
||||
|
||||
.span:hover .span_title {
|
||||
border-radius: 50%;
|
||||
background: #a5f5b8;
|
||||
color: #ff0000;
|
||||
}
|
||||
</style>
|
||||
```
|
||||
|
||||
在对应的四个方式的调用中：
|
||||
|
||||
`直接使用`：完全没有问题
|
||||
|
||||
`拼接使用`：这个在`css`中没有问题，不过在`scss`中会出现错误，这个在下面的`scss`中会有详细介绍
|
||||
|
||||
`对象调用`：对象的调用和直接使用类似，不过不同的是，需要使用引号的包裹才能正常使用，如果直接书写会报错
|
||||
|
||||
`组合使用`：完全没问题
|
||||
|
||||
- 在`less`中：
|
||||
|
||||
使用的数据同样是上面给出的数据，这里直接改样式的内容了
|
||||
|
||||
```css
|
||||
<style scoped lang="less">
|
||||
// 使用变量承接
|
||||
@height: v-bind(div_height);
|
||||
|
||||
.div {
|
||||
width: 400px;
|
||||
/* 直接使用 */
|
||||
height: @height;
|
||||
background: v-bind(div_color);
|
||||
|
||||
.span {
|
||||
@width: v-bind('span.width');
|
||||
|
||||
/* 对象调用 */
|
||||
width: @width;
|
||||
height: v-bind('span.height');
|
||||
background: v-bind('span.color');
|
||||
display: flex;
|
||||
justify-content: center;
|
||||
align-items: center;
|
||||
|
||||
.span_title {
|
||||
@transition: v-bind(transition);
|
||||
width: 100px;
|
||||
height: 100px;
|
||||
background: #000;
|
||||
color: white;
|
||||
/* 组合使用 */
|
||||
transition: all .9s @transition;
|
||||
}
|
||||
|
||||
&:hover .span_title {
|
||||
border-radius: 50%;
|
||||
background: #a5f5b8;
|
||||
color: #ff0000;
|
||||
}
|
||||
}
|
||||
}
|
||||
</style>
|
||||
```
|
||||
|
||||
`直接使用`：没有问题
|
||||
|
||||
`拼接使用`：**存在问题**，在下面尝试进行了解决
|
||||
|
||||
`对象调用`：没问题
|
||||
|
||||
`组合使用`：没问题
|
||||
|
||||
<h3>问题：</h3>
|
||||
|
||||
> 在拼接使用有几种方式：
|
||||
>
|
||||
> ```js
|
||||
> // 定义使用的数据
|
||||
> let width = 400
|
||||
> ```
|
||||
>
|
||||
> ```css
|
||||
> // 直接拼接
|
||||
> @width: v-bind( width + 'px');
|
||||
> width: @width;
|
||||
>
|
||||
> // 拿到内容后拼接
|
||||
> @width: v-bind(width) + 'px';
|
||||
> width: @width;
|
||||
>
|
||||
> // 使用时拼接
|
||||
> @width: v-bind(width);
|
||||
> width: @width + 'px';
|
||||
>
|
||||
> ```
|
||||
>
|
||||
> 常用的拼接方法一般为这几种（如果有欠缺还请补充），这几种方式都进行了尝试，其中第二种第三种会没有效果，第一种会直接报错
|
||||
|
||||
|
||||
|
||||
<h3>问题分析（尝试解决）：【这部分会很长，如果不想看，可以直接跳到解决方法】</h3>
|
||||
|
||||
首先是第一种，如果使用的话会直接报错，报错内容为：
|
||||
|
||||
|
||||
|
||||
因为`less`的直接报错，导致定义的变量压根就没有被编译出来，从而报错
|
||||
|
||||
第二种和第三种错误一样：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
在这种使用方式中，变量可以正确承接，但是不能完成拼接的操作，导致只有变量而没有单位，并且可以看出最终都被翻译为`var(--变量名)`来执行，所以顺便也对`var()`进行了拼接测试
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
这里进行调用内容的定义，并且模仿编译后的内容，进行使用，在这种情况下尝试使用拼接
|
||||
|
||||
> 尝试的拼接方式：
|
||||
>
|
||||
> `直接拼接`：
|
||||
>
|
||||
> ```css
|
||||
> :root{
|
||||
> --test:400 + 'px';
|
||||
> }
|
||||
> /* 使用 */
|
||||
> width: var(--test);
|
||||
> ```
|
||||
>
|
||||
> `接受变量后拼接`：
|
||||
>
|
||||
> ```css
|
||||
> :root{
|
||||
> --test:400 + 'px';
|
||||
> }
|
||||
> /* 使用 */
|
||||
> width: var(--test+ 'px');
|
||||
> ```
|
||||
>
|
||||
> `继承后拼接`：
|
||||
>
|
||||
> ```css
|
||||
> :root{
|
||||
> --test:400 + 'px';
|
||||
> }
|
||||
> /* 使用 */
|
||||
> width: var(--test) + 'px';
|
||||
> ```
|
||||
|
||||
结果也非常让不出意外的都不行，并且在第二种方式也是直接报错的，在寻找问题的过程中，发现了更加`amazing`的事情：
|
||||
|
||||
|
||||
|
||||
|
||||
这个变量压根就没定义，或者说没被识别到，所以重新模仿`Vue`直接定义行内样式，并且使用拼接尝试：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
这种直接的拼接方式直接将所有内容都进行了拼接，再换一种思路：使用`V-bind`这个V-bind指的是数据的而不是样式：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
这次问题得到了解决，并且样式数据也是响应式的单个数据，并且也是在`less`中正确使用，应该也算解决问题吧
|
||||
|
||||
<h3>解决方式（思路）：</h3>
|
||||
|
||||
将变量的内容在`行内样式`使用拼接的方式进行定义，然后在定义的`less或scss`中进行使用，因为定义的样式是行内样式，所以优先级和变量出现的位置，都是在使用之前，所以可以正常使用
|
||||
|
||||
<h3>完整代码：</h3>
|
||||
|
||||
> 使用数据的定义：
|
||||
>
|
||||
> ```js
|
||||
> // 大部分数据和预先提供的数据一样（这里只写了新增数据）
|
||||
> let test = 400
|
||||
> ```
|
||||
>
|
||||
> 页面结构：
|
||||
>
|
||||
> ```html
|
||||
> <!-- 改变的内容为下面这行（其他内容和原来内容保持一致）-->
|
||||
> <!-- 【在这里对要使用的数据进行单位的绑定】-->
|
||||
> <div class="div" :style="{'--test' :test + 'px'}">
|
||||
> <div class="span">
|
||||
> <div class="span_title">
|
||||
> 这是测试文字
|
||||
> </div>
|
||||
> </div>
|
||||
> </div>
|
||||
> ```
|
||||
>
|
||||
> 样式的使用：
|
||||
>
|
||||
> ```css
|
||||
> <style scoped lang="less">
|
||||
> // 承接使用
|
||||
> @width: var(--test);
|
||||
>
|
||||
> .div {
|
||||
> /* 使用 */
|
||||
> width: @width;
|
||||
> /* 或者直接使用 */
|
||||
> width: var(--test);
|
||||
> height: 400px;
|
||||
> background: red;
|
||||
> }
|
||||
> </style>
|
||||
> ```
|
||||
>
|
||||
|
||||
|
||||
|
||||
在`css`的测试中几种方式也都能完美运行，并且在`less`的特有的数据绑定中也都没有问题，对于`拼接使用`是可以正常使用的。
|
||||
|
||||
我用的工具是`webstorm`less也是唯一一个没有报错的提示的（工具内的报错提示，可能不认识新内容把）
|
||||
|
||||
- 在`scss`中：
|
||||
|
||||
```css
|
||||
<style scoped lang="scss">
|
||||
// 使用变量承接
|
||||
$width: v-bind(width + 'px');
|
||||
$height: v-bind(div_height);
|
||||
|
||||
.div {
|
||||
/* 拼接使用 */
|
||||
width: $width;
|
||||
/* 直接使用 */
|
||||
height: $height;
|
||||
background: v-bind(div_color);
|
||||
|
||||
.span {
|
||||
$width: v-bind('span.width');
|
||||
|
||||
/* 对象调用 */
|
||||
width: $width;
|
||||
height: v-bind('span.height');
|
||||
background: v-bind('span.color');
|
||||
display: flex;
|
||||
justify-content: center;
|
||||
align-items: center;
|
||||
|
||||
.span_title {
|
||||
$transition: v-bind(transition);
|
||||
width: 100px;
|
||||
height: 100px;
|
||||
background: #000;
|
||||
color: white;
|
||||
/* 组合使用 */
|
||||
transition: all .9s $transition;
|
||||
}
|
||||
|
||||
&:hover .span_title {
|
||||
border-radius: 50%;
|
||||
background: #a5f5b8;
|
||||
color: #ff0000;
|
||||
}
|
||||
}
|
||||
}
|
||||
</style>
|
||||
```
|
||||
|
||||
`scss`相对`less`一些方法更加灵活，在`v-bind()`的使用中，拼接使用会出现错误，这个暂时按下不表，在原理中会详细阐述
|
||||
|
||||
- 执行原理：
|
||||
|
||||
`v-bind() in css`并没有进行劫持或者其他操作，他主要完成的任务是将`v-bind()`中的内容通过自定义属性的方式进行了重新定义，在编译后代码中可以看到
|
||||
|
||||
|
||||
|
||||
|
||||
所有的数据直接在自定义属性中进行，并且直接对应引用，自定义属性的内容的改变影响视图的效果，从而达到数据影响视图的效果，这个在使用中`less`,`css`中完全没有问题
|
||||
|
||||
但是，在`scss`中，因为编译之后`名字无法进行匹配`从而造成样式的丢失
|
||||
|
||||
|
||||
|
||||
|
||||
可以看到，使用的名字和编译的名字并不匹配，从而出错，这个使用时需要注意
|
||||
|
||||
|
||||
+10
-4
@@ -1,4 +1,13 @@
|
||||
# 写在前面
|
||||
---
|
||||
date: '2022-08-09T10:33:58+08:00'
|
||||
draft: false
|
||||
title: '在JavaScript获取Promise的状态'
|
||||
keywords: [ 'JavaScript','Promise' ]
|
||||
tags: [ 'JavaScript' ]
|
||||
categories: [ 'skill' ]
|
||||
---
|
||||
|
||||
# 写在前面
|
||||
|
||||
本文属于对`stackoverflow`中写法的解析，原文链接：[**Stack Overflow** ](https://stackoverflow.com/questions/30564053/how-can-i-synchronously-determine-a-javascript-promises-state)
|
||||
|
||||
@@ -88,6 +97,3 @@
|
||||
})
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
`本文仅代表鄙人粗鄙的拙见，可能出现疏忽和纰漏，如果您发现了问题还望与我沟通联系，谢谢。`
|
||||
@@ -0,0 +1,118 @@
|
||||
---
|
||||
date: '2024-08-04T19:33:58+08:00'
|
||||
draft: false
|
||||
title: 'TypeScript 应该被放弃吗'
|
||||
keywords: [ 'react','vue','ts' ]
|
||||
tags: [ 'react','vue','ts']
|
||||
categories: [ 'think' ]
|
||||
|
||||
---
|
||||
|
||||
### TypeScript 应该放弃吗
|
||||
|
||||
--------
|
||||
|
||||
抛出这个问题主要基于22年和23年发生的一些事件：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
并且Svelte 不是第一个放弃 TypeScript 的前端框架。早在 2020 年，Deno 就迁移了一部分內部 TypeScript 代码到 JavaScript，以减少构建时间。
|
||||
|
||||
|
||||
|
||||
并且这些大牛放弃 TypeScript 似乎还加快了工作进度，但这个选择是否应该被普通开发者所选择？
|
||||
|
||||
搜了很多文章，但是大部分都在将一些很正确的废话，目前来看只有下面两片有参考价值。
|
||||
|
||||
##### 第一篇：[Turbo 8 正在放弃 TypeScript (hey.com)](https://world.hey.com/dhh/turbo-8-is-dropping-typescript-70165c01)
|
||||
|
||||
|
||||
>
|
||||
> 这是原文，正式这篇文章，引来了众多讨论
|
||||
|
||||
文章的主要观点如下：
|
||||
|
||||
> TypeScript 只是妨碍了我。不仅因为它需要显式的编译步骤，还因为它用类型体操污染了代码
|
||||
|
||||
—— 多余类型判断只会降低效率
|
||||
|
||||
文章没有多长，几乎没有太多参考价值，但毕竟是原文，还是搬过来比较好。
|
||||
|
||||
并且对于这篇文章，Reddit的评论区也是活力十足
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
并且在知乎对于这个问题的评价更加激进：
|
||||
|
||||
|
||||
|
||||
以下是文字版本：
|
||||
|
||||
> 前端届盛产大牛，整点别人看不懂的代码，硬说函数式然后猛劲宣传就能当大牛。
|
||||
>
|
||||
> 搞计算机其实有一点不好，就是你以为有些应该不在世的大师他都活着呢。
|
||||
>
|
||||
> 算法分析之父高德纳还在呢。
|
||||
>
|
||||
> WindowsNT内核之父David Cuttler也还在呢。
|
||||
>
|
||||
> Linux内核之父Linus还到处喷人呢。
|
||||
>
|
||||
> GUI和面向对象之父Allen Kay也还在呢。
|
||||
>
|
||||
> Pascal总架构师，Delphi和C#之父，编程语言届的传奇**Anders Hejlsberg**也还在努力工作呢。
|
||||
>
|
||||
> 我不明白某些在社区当网红的不入流货色是怎么敢被封为大牛还大放厥词的。
|
||||
>
|
||||
> 对了，TypeScript就是Anders搞的。
|
||||
|
||||
|
||||
|
||||
无论是知乎还是Reddit的讨论都是相对激进，并拳拳到肉那种，只顾着输出情绪了。不过总结起来大致为以下两个观点：
|
||||
|
||||
1. Turbo 8 并不是什么知名项目，没人在意他是否放弃 TypeScript
|
||||
2. Turbo 8 的作者（也是文章作者），经常写类似的文章来唱反调
|
||||
3. 文章除了说明了类型让他更加麻烦了，并且有提出其他有力依据，所以被Reddit评论区狂怼
|
||||
4. 这个大牛是虚假宣传的，为了博眼球臆造出来的，而那些真正的大牛创造了TypeScript
|
||||
|
||||
|
||||
|
||||
当然**无意义的情绪输出不能解决任何问题**，所以也有下面这个文章通过多个方面来讨论为什么那些社区项目会放弃TypeScript
|
||||
|
||||
|
||||
|
||||
##### 第二篇：[“根本不需要 TypeScript，JS + JSDoc 够了”，大佬说我想多了](https://my.oschina.net/u/6852546/blog/10114672)
|
||||
|
||||
文章的主要观点如下：
|
||||
|
||||
> 某些场景下，写 TypeScript 会带来一些额外成本。一些开源库的源码，核心逻辑可能就几十行，但为了实现准确的类型提示，写出来的类型体操反而远远多于核心源码，孰是孰非对于不同的开发者有不同的准绳，需要找到其中的平衡点。
|
||||
|
||||
—— 对于特定场景，TypeScript 确实更麻烦了
|
||||
|
||||
> 使用了 TypeScript 的项目改回使用 JavaScript 是很少见的，更多的项目是从 JavaScript 升级到 TypeScript。TypeScript 完善了 JavaScript 的类型系统，使得代码的可维护性更高了.
|
||||
|
||||
—— 相对来说，TypeScript 相对于 JavaScript 是更加受欢迎的，并且被更多项目所接受
|
||||
|
||||
> **框架和类库的开发者，往往需要考虑到很多 edge case**，在这种情况下，编写完善的类型是一件很费心力的事，代码量会多了不少，从而会导致维护成本的增加。
|
||||
|
||||
—— 放弃 TypeScript 的更多是那些公共仓库的维护者，而他们需要考虑所有有可能出现的情况，会有非常多的边缘判断来减少异常，这也造成了如果使用 TypeScript反而会更麻烦
|
||||
|
||||
> TypeScript 的成功无需质疑，已经有无数的项目证明了它的成功。开发者并没有 “嫌弃” TypeScript，只是认为并不是所有项目都适合使用 TypeScript。
|
||||
|
||||
> **有人认为，** **TypeScript** **的出现是因为一般人驾驭不了** **JavaScript** **，有人则觉得 “水平越差的人越喜欢自由”，你怎么看？这两个语言的选择跟程序员的水平有关吗？**
|
||||
>
|
||||
> - 平时可没少见有同学吐槽，**好好的 TypeScript 项目，被人提交了一堆 Any**。也见过很多吐槽接手了一个 TypeScript 仓库，要硬着头皮看一大堆类型定义，搞清楚这些奇奇怪怪的类型是如何工作的。我觉得语言的选择主要看团队的工程化和规范化程度，过犹不及。如果一个 TypeScript 类库写了一大堆类型，但却连一个单测都没有，那我觉得它是不合格的。
|
||||
> - JavaScript 和 TypeScript 不能用来衡量程序员的水平。对于简单的项目或者个人项目而言，JavaScript 可能更加轻量和灵活，但对于需要大团队协作，复杂的项目而言，TypeScript 的类型系统就可以带来更好的代码维护性和可靠性了。
|
||||
|
||||
|
||||
|
||||
该文章相对来说理性了很多，通过一些采访来尽量还原更加客观的事实，并且对于 TypeScript 的选择相对来说没有那么难决断，那些仓库的作者因为繁琐的 **edge case** 放弃了 TS，但这并不代表他没有一点自己的用武之地，在常规的项目中，尤其是大型的多人合作项目中，TS也会是优先的选择。
|
||||
|
||||
并且无论是TS还是JS都能做出很好的产品，二者没有高低贵贱之分，如果一个TS项目写满了 `Any` 那不如直接切换为 JS 反而在某种程度还更能节约代码量了
|
||||
|
||||
@@ -0,0 +1,209 @@
|
||||
---
|
||||
date: '2024-08-04T19:33:58+08:00'
|
||||
draft: false
|
||||
title: 'Vue还是React?'
|
||||
# 文章置顶
|
||||
weight: 1
|
||||
keywords: [ 'html','css','react','vue','ts' ]
|
||||
tags: [ 'react','vue','ts']
|
||||
categories: [ 'think' ]
|
||||
|
||||
---
|
||||
|
||||
[//]: # (# 文档编号：10003)
|
||||
|
||||
### Vue和React、Nextjs如何选择
|
||||
|
||||
--------
|
||||
|
||||
`Vue` 在大前端时代，在国内市场可谓是大杀特杀，几乎以压倒性的优势占领着国内市场，并且随着 2020 年`Vue3`的发布，以及`Vite`的推出，其生态更加完善，基本是国内市场做前端的首选语言。
|
||||
|
||||
|
||||
|
||||
但和国内相悖的是，在`JetBrains`与`StackOverflow`在2023年的数据报告中，在前端方面数据，`Node`和`React`以压倒性优势领先其他语言
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
2023JavaScript趋势报告：
|
||||
|
||||
|
||||
|
||||
和国内不同的是，`React`在国外保持着惊人的活力
|
||||
|
||||
但也有很多反对`React`的声音，以及关于`React`辩论的文章，如：
|
||||
|
||||
[你因为 React 而忘记（或从来不知道）的事情 - Josh Collinsworth 博客](https://joshcollinsworth.com/blog/antiquated-react)
|
||||
|
||||
[React 的自我实现预言 - Josh Collinsworth 博客](https://joshcollinsworth.com/blog/self-fulfilling-prophecy-of-react)
|
||||
|
||||
[辛辣的 React 辩论秀 🌶️ （JS Party #244） (changelog.com)](https://changelog.com/jsparty/244)
|
||||
|
||||
|
||||
|
||||
如果各位有兴趣可以读原文，我这里为每篇文章简单的总结。
|
||||
|
||||
#### 第一篇：[你因为 React 而忘记（或从来不知道）的事情 - Josh Collinsworth 博客](https://joshcollinsworth.com/blog/antiquated-react)
|
||||
|
||||
>
|
||||
> 该文章也是被 `2023 JavaScript 行业调研报告` 所提到的文章，并且一些观点的确值得思考，但有的就一般了，为了准确传达原作者的意思，我这里会尽量中立的概括，也会引用部分原文进行对应部分内容的解释。
|
||||
|
||||
1. ##### 并不是所有好的事物都会流行。
|
||||
|
||||
> 回首往事，我意识到：我天真地相信，任何好东西都不可避免地会流行起来——因此，任何值得了解的东西最终都会自己出现。
|
||||
|
||||
|
||||
>
|
||||
> 作者开篇就提到了好的事物并不会自然的流行，自然而然的出现到你面前，也就说明了另一个意思：**出现在你面前的，流行起来的可能并不是最好的选择**
|
||||
|
||||
2. ##### `React`已经老化了
|
||||
|
||||
> React 从早期的框架游戏中受益匪浅;它设定了标准。但这在敏捷性和适应性方面存在严重缺陷。自 2013 年左右成立以来，React 做出的每一个决定都是另一层技术债务——它的新同时代人不受其约束。
|
||||
>
|
||||
> [再次引用亚历克斯的话](https://toot.cafe/@slightlyoff/110512849934452558)：
|
||||
>
|
||||
> > React 是 '13 技术，旨在 '08 约束。在 2023 年，它没有任何创新之处;事实上，这是现代获得函数式响应式前端编程的最慢方法......
|
||||
|
||||
3. ##### `React`是定制的，这使其在不同框架之间很难移植，几乎不和其他平台兼容
|
||||
|
||||
> 使用 React，每当我们需要一个模块、一个小部件或一个库来做一些特定的事情（旋转木马、地图、手风琴或其他任何东西）时，*它必须是 React 的东西*;一个普通的 Web 东西或一个普通的 JavaScript 东西是行不通的。React 的所有规则以及对组件生命周期状态和怪癖的处理意味着任何*没有*明确为 React 编写的可用包或库都可能无法工作。
|
||||
>
|
||||
> **React 训练我们，需要*专门为某个框架*构建东西。但这已经不是真的了，可以说永远不应该是这样。**
|
||||
|
||||
作者在这里举了个例子，通过框架之间的对比衬托`React`的独断专行
|
||||
|
||||
> [Preact Signals](https://preactjs.com/guide/v10/signals/) 就是一个非凡的例子：虽然它是为使用 Preact 而构建的，但它可以在*任何*框架中导入和使用，甚至可以在普通的 JavaScript 中使用。Web 组件也与几乎任何现代非 React 框架兼容。
|
||||
|
||||
4. ##### React 钩子实际上有点过时了
|
||||
|
||||
> 钩子是一种极好的模式，React 的普及值得称赞。但几乎所有其他框架都做得更好，规则更少，样板更少。
|
||||
|
||||
5. ##### `React`相对更加不智能
|
||||
|
||||
> 如今，框架足够聪明，可以处理这种事情，而不需要你握住他们的手并解释他们应该做什么。
|
||||
|
||||
"但React还是需要你做这些精细化管理"
|
||||
|
||||
6. ##### 服务器端渲染不再特别
|
||||
|
||||
> 几年前，曾经有一段时间，当涉及到服务器渲染的内容（主要是通过Next JS）时，React几乎是唯一的选择。人们理所当然地对 React 可以在服务器上以 HTML 形式呈现的想法感到兴奋，而不是在客户端上作为单页应用程序 （SPA） 呈现。速度和SEO的收益是不容忽视的，最初，其他框架需要一点时间才能赶上。不过选择更多框架都做到了。
|
||||
|
||||
7. ##### React 是由 Facebook 创建的，目的是解决 Facebook 独特的一系列问题
|
||||
|
||||
> 在 React 中使用表单是出了名的麻烦，因为每个用户击键都是一个两步过程：从输入中获取值;然后设置状态以匹配它（这反过来又不必要地重新渲染输入，以包含它已经完成的确切值，但与 React 状态同步）。当然，它通常太快而无法注意到，但这是很多额外的工作。
|
||||
>
|
||||
> 这就是为什么 React 的表单库激增的原因
|
||||
|
||||
8. ##### React 在性能上远远落后
|
||||
|
||||
> 在许多情况下，React 在性能方面（这里我指的是捆绑包大小和执行速度）落后 2 倍或更多。（捆绑包本身可以是 10 倍或更多。最新一轮[的 JS Web 框架基准测试](https://github.com/krausest/js-framework-benchmark)显示，React 的性能平均比 Solid 慢近 50%，比 Vue 慢 25%，比 Svelte 慢 40%，比 Preact 慢 35%。（其他框架在此特定测试中不可用。
|
||||
|
||||
9. ##### Svelte 是没有废话的 React
|
||||
|
||||
> Svelte 使用起来非常简单，相对容易学习（特别是如果你已经来自 React 世界，甚至语法通常也很相似），在几乎所有情况下都表现得更好，并且能够做任何 React 的事情，甚至更多
|
||||
|
||||
这也是作者留下的解决方案，并且根据作者本人所说，他本人的所有博客和网站都是有此完成.
|
||||
|
||||
|
||||
|
||||
#### 第二篇：[React 的自我实现预言 - Josh Collinsworth 博客](https://joshcollinsworth.com/blog/self-fulfilling-prophecy-of-react)
|
||||
|
||||
|
||||
>
|
||||
> 该篇文章是同一个作者在不同时期写的，本文完成时间更早，同样是对`React`的批评
|
||||
|
||||
1. ##### React 除了受欢迎之外，什么都不擅长。
|
||||
|
||||
> 让我在 React 和根本没有前端框架之间做出选择，并且给定任何足够大小或复杂度的项目，我很乐意接受 React，非常感谢。
|
||||
>
|
||||
> React 为其他框架正在做和已经做的很多事情奠定了基础。[Vue 3](https://vuejs.org/guide/introduction.html) 及其组合 API 显然受到了 React hooks 的启发。[Svelte](https://svelte.dev/) 的许多约定都来自 React。[Nuxt](https://nuxtjs.org/) 是我使用过并喜欢的 Vue 框架，它的许多想法（以及 75% 的名称）都来自 [Next](https://nextjs.org/)，一个 React 元框架。就此而言，整个基于组件的前端设计和开发模型的当前状态（哈）很大程度上归功于 React——尽管应该指出的是，其他人也帮助铺平了道路。
|
||||
>
|
||||
> **React 做了它擅长的事情，但它并没有比其他*框架做得更好。***
|
||||
|
||||
2. ##### 更多的社区和支持并不代表他是一个更好的选择
|
||||
|
||||
> 一个大的社区也可能是一个缺点，尤其是在所谓的“无主见”框架的情况下，比如 React。**这可能意味着有太多的套餐可供选择，以及太多不同的、相互竞争的意见，你必须在两者之间做出决定并采取立场。**
|
||||
|
||||
3. ##### 多年来，React 的满意度和兴趣一直在稳步下降，而其使用率却持平
|
||||
|
||||
> React 很容易成为最常用的前端框架，也是知名度最高的前端框架，但在今年的 [JS 现状调查结果](https://2021.stateofjs.com/en-US/libraries/front-end-frameworks/)中，React 在满意度方面落后于 Solid 和 Svelte。React 在兴趣方面也排在 Svelte、Solid 和 Vue 之后（对于 React 来说，兴趣*低于 50%）*。
|
||||
>
|
||||
> React 在 [StackOverflow 调查](https://insights.stackoverflow.com/survey/2021#technology-most-popular-technologies)中远远落后于 Svelte，也仅略微领先于 Vue。
|
||||
|
||||
4. ##### 为什么 React 会保持领先地位呢？
|
||||
|
||||
> “从来没有人因为选择 React 而被解雇”
|
||||
>
|
||||
> 这是安全的选择。它可能不是每个人的最爱，但不一定是。它可能也不会是任何人最不喜欢的。它会完成工作。
|
||||
|
||||
像`Vue`一样，因为市场需要所以企业招聘，因为企业招聘，所以更多人学习，同样的，因为会的人多，所以企业招聘。他们完成了各自的闭环，但**这个选择可能不是最明智的，但绝对是最安全的。**
|
||||
|
||||
|
||||
|
||||
#### 第三篇：[辛辣的 React 辩论秀 🌶️ （JS Party #244） (changelog.com)](https://changelog.com/jsparty/244)
|
||||
|
||||
|
||||
>
|
||||
> 本篇文章主要是关于是否应该放弃`React`而投身其他框架，以及`React`自身存在问题的讨论
|
||||
>
|
||||
> 本篇文章是对一个讨论节目的翻译版本，会有很多观点，本文只总结，不站队
|
||||
|
||||
##### 观点一：React赢被放弃
|
||||
|
||||
> - React 或多或少是任何给定项目的默认选择。它已经达到了临界质量，感觉就像是一切的安全默认值.
|
||||
>
|
||||
> - 从性能到捆绑包大小，到入职，再到复杂性、开发体验......一般来说，所有这些事情都是 React 本身并不能真正获胜的领域，在这些领域有更好的选择
|
||||
> - 当你缩小并查看大局时，你会意识到 React 在几乎每个给定的类别中都非常平庸，它真正擅长的唯一类别就是成为流行的东西。
|
||||
|
||||
##### 观点二：React有自己的难处，他不完美但已经做的很好了，并且也被很多人所接受
|
||||
|
||||
> - 当你流行时，你必须处理所有不同的情况。所以你不能只关注一件事而忽略其他。
|
||||
> - 如果我只关心绝对性能，我会发布静态 HTML。
|
||||
> - Stack Overflow 调查，我注意到 React 的满意度为 84%，高于 Vue，几乎是 Angular 的两倍，紧随 Svelte 之后，使用率更高。如果React被很多人使用，如果他不被大多数人满意，那他的满意度将会低很多，但事实上这并没有
|
||||
|
||||
##### 观点三：React更像一个仁慈的君主
|
||||
|
||||
> - 拥有一个几乎可以在任何地方使用的框架不是很好吗？我想要一个带有线条的 3D 旋转地球仪的库。你知道吗？你只需谷歌一下，它就在那里。你把它拉进来。很简单。生活很美好。（作为 2015 年框架战争的老兵，我只想说我们不想回到那个时代。每周都要面对一个新的框架，这让人筋疲力尽。）
|
||||
> - 如果我们要有一个统治框架，难道我们不希望它没有主见吗？所以 React 真的很好，因为它基本上只是一个带有最小状态管理解决方案的渲染库。有许多其他东西建立在 React 之上，这使得它与其他框架相当。所以即使你考虑元框架，也有很多流行的框架。
|
||||
> - 如果你了解 JavaScript，你几乎了解 React 的所有内容。他不会像Angular那样有很多新的“魔法”（这里指的是Angular引入的新的改变增加了学习成本，如管道，过滤器等）
|
||||
|
||||
|
||||
|
||||
##### 观点四：从公司架构思考问题
|
||||
|
||||
> React 的优势和我们遇到的摩擦都与它仍然由 Facebook 构建的事实有关，而 Facebook 的重点和优化选择都是为了解决 Facebook 所面临的问题。这些问题与许多公司在构建 JavaScript 应用程序时遇到的问题相当吻合，但一方面它们肯定是错的。
|
||||
>
|
||||
> 实际上，我认为你会在 Angular 中遇到一些相同的问题。Angular 仍然主要由 Google 想要什么和 Google 需要什么驱动。所以我认为，如果 Angular 达到这个水平——那么，早期的 Angular 确实很受欢迎，然后经历了很多这样的事情。
|
||||
>
|
||||
> 现在，如果你看看满意度，你会发现人们对 Angular 非常不满意，尽管有很多人在使用它。React 也可能会走这个老路……
|
||||
>
|
||||
> Vue 目前感觉更像是社区驱动。我觉得 Svelte 也在朝这个方向发展，尽管它们都是从仁慈独裁者的方式开始的。它们都拥抱了更广泛的社区，而不是只满足一家公司的需求
|
||||
|
||||
|
||||
|
||||
这几篇是一些影响力比较大的文章，相对来说观点已经比较全面了，大致分为以下几点：
|
||||
|
||||
1. React 因为时代原因已经有些过时了，因为使用的人很多，所以他每一次新功能的增加都将非常谨慎像现在的Java一样，虽然版本号一路突飞猛进，但是变化依然不大
|
||||
2. React 的除了流行外别无优点，整体的性能，包大小，等都不够拔
|
||||
|
||||
但React也有其自己的优点：
|
||||
|
||||
1. 最强大的社区支持，你几乎能找到你想要的所有库
|
||||
2. React不是一个框架，而是一个库，你多了解 JavaScript 就有多了解 React。他可以让你进行最大限度的定制
|
||||
|
||||
|
||||
> 本文参考的文章如下：
|
||||
> [JetBrains2023行业状况调研](https://www.jetbrains.com/zh-cn/)
|
||||
>
|
||||
> [StackOverflow2023行业调查问卷](https://survey.stackoverflow.co/2023/)
|
||||
>
|
||||
> [你因为 React 而忘记（或从来不知道）的事情 - Josh Collinsworth 博客](https://joshcollinsworth.com/blog/antiquated-react)
|
||||
>
|
||||
> [React 的自我实现预言 - Josh Collinsworth 博客](https://joshcollinsworth.com/blog/self-fulfilling-prophecy-of-react)
|
||||
>
|
||||
> [辛辣的 React 辩论秀 🌶️ （JS Party #244） (changelog.com)](https://changelog.com/jsparty/244)
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
date: '2025-01-05T19:33:58+08:00'
|
||||
date: '2024-08-07T19:33:58+08:00'
|
||||
draft: false
|
||||
title: '中西文混排时汉字与拉丁字母之间差异'
|
||||
keywords: ['中西文混排时汉字与拉丁字母之间差异']
|
||||
@@ -8,8 +8,6 @@ categories: ["设计"]
|
||||
|
||||
---
|
||||
|
||||
[//]: # (# 文档编号：10001)
|
||||
|
||||
[//]: # (## 中英文混排时汉字与拉丁字母之间是否要有空格)
|
||||
|
||||
|
||||
+54
-54
@@ -1,5 +1,5 @@
|
||||
---
|
||||
date: '2025-01-05T19:33:58+08:00'
|
||||
date: '2024-08-03T19:33:58+08:00'
|
||||
draft: false
|
||||
title: '主流网站主页布局展示内容及渲染方式调研'
|
||||
keywords: ['主流网站主页布局展示内容及渲染方式调研']
|
||||
@@ -15,11 +15,11 @@ categories: ["设计"]
|
||||
|
||||
如：
|
||||
|
||||
<img src="/10002/image-20240709144917869.png" alt="/10002/image-20240709144917869" />
|
||||
<img src="/blog/2024/08/10002/image-20240709144917869.png" alt="/blog/2024/08/10002/image-20240709144917869" />
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -27,33 +27,33 @@ categories: ["设计"]
|
||||
|
||||
## **标签（板块）**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -67,17 +67,17 @@ categories: ["设计"]
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -89,29 +89,29 @@ categories: ["设计"]
|
||||
|
||||
## 排行（热门）
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -127,11 +127,11 @@ categories: ["设计"]
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -149,19 +149,19 @@ categories: ["设计"]
|
||||
|
||||
### 列表形式
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -169,39 +169,39 @@ categories: ["设计"]
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
--------
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 问答形式
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 卡片形式
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 预览形式
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
date: '2025-01-05T19:33:58+08:00'
|
||||
date: '2024-08-05T19:33:58+08:00'
|
||||
draft: false
|
||||
title: '登录功能的思考'
|
||||
# 为文章添加分类标签
|
||||
@@ -103,7 +103,8 @@ keywords: ['登录功能']
|
||||
8. 然后服务器将加密后的密文发送给客户端。
|
||||
9. 客户端收到服务器发送来的密文，用客户端密钥对其进行对称解密，得到服务器发送的数据。这样HTTPS中的第二个HTTP请求结束，整个HTTPS传输完成。
|
||||
|
||||
<img src="/10004/sp5zj58b89.webp" alt="img" style="zoom:80%;" />
|
||||
|
||||
|
||||
|
||||
它通过以下方式保证数据的安全性：
|
||||
|
||||
@@ -1,486 +0,0 @@
|
||||
---
|
||||
date: '2025-01-05T19:33:58+08:00'
|
||||
draft: false
|
||||
title: '开发语言的选择'
|
||||
# 文章置顶
|
||||
weight: 1
|
||||
keywords: [ '开发语言的选择','html','css','react','vue','ts','kotlin','java' ]
|
||||
tags: [ 'react','vue','ts','kotlin']
|
||||
categories: [ 'react','vue' ]
|
||||
|
||||
---
|
||||
|
||||
[//]: # (# 文档编号：10003)
|
||||
|
||||
**本文主要包含：**
|
||||
|
||||
<div style="color:red;">
|
||||
<ol>
|
||||
1. 对Kotlin语言以及他为何能替代Java的解释
|
||||
</ol>
|
||||
<ol>
|
||||
2. React是否就是前端最终归宿的讨论
|
||||
</ol>
|
||||
<ol>
|
||||
3. TS 应该被放弃吗？为什么那些大牛和社区会放弃TS？
|
||||
</ol>
|
||||
<ol>
|
||||
4. 为什么反对跨平台框架
|
||||
</ol>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
> 对于使用语言的几乎没什么可争议的，整体的框架基本都是固定的，只是细节内容的变化
|
||||
>
|
||||
> 比如后端一定是Java或者是GO，绝不可能使用CPP或者他的替代者Rust；
|
||||
>
|
||||
> 而前端因为种类繁杂，不仅有一种以虚拟Dom为开发思路的框架，如（Vue，React），也有新兴的抛弃虚拟Dom方案的框架，如（servlet），还有基于Vue或React的新框架如（Nextjs，Nust等等）
|
||||
|
||||
对于语言的选择主要基于：**是否被大多数人接受**，一个项目想要长久的发展，出现的一些问题希望更好的解决，选择使用大多数人常用的解决方案往往可以更快的解决问题
|
||||
|
||||
|
||||
|
||||
基于以上准则，本文主要包含以下内容：
|
||||
|
||||
- ###### [Java还是Kotlin](#Java还是Kotlin)
|
||||
|
||||
- ###### [Vue和React、Nextjs如何选择](#Vue和React、Nextjs如何选择)
|
||||
|
||||
- ###### [TypeScript 应该放弃吗](#TypeScript 应该放弃吗)
|
||||
|
||||
- **[为什么不使用跨平台框架](#为什么不使用跨平台框架)**
|
||||
|
||||
|
||||
|
||||
### Java还是Kotlin
|
||||
|
||||
-------
|
||||
|
||||
`Java`目前几乎是最最烂大街的语言，一个不懂代码的人，他可能不知道`JavaScript`，但是他很大概率听过`Java`，并且`Java`自`1995`年在`Sun`公司发明后一路迭代，以独有的`JVM`虚拟机在各平台相对统一的表现和兼容性，在服务端以及安卓端一路高歌，现在也几乎成为了服务器开发的首选语言（除了这两年爆火的`GO`），并且得益于`Java`的强大以及一些组织（`apache`）的卓越贡献，让`Java`在生态上也发展迅速，如（`Spring`,`MyBaits`）等，所以无论是公司还是个人，新的服务端项目选择几乎是毋庸置疑的。
|
||||
|
||||
而`GO`语言这两年被`Google`一直推崇，发展也非常快，但是因为是新兴语言，在可用库以及复杂问题的解决方案上相对更加欠缺（我们不能浪费时间在解决非业务问题上），所在对于稳定解决方案，Java依然是首选。不过这也带来一个问题，既然`GO`都不能从`Java`那里抢到饭碗：
|
||||
|
||||
##### 那何为`Kotlin`，他凭什么能和`Java`相提并论？
|
||||
|
||||
`Kotlin`是`JetBrains`公司（就是开发`IDEA`的那个`JetBrains`）在`2011年`推出，并随后开源
|
||||
|
||||
2017年`Google I/O`大会上，`Google`宣布将对`Kotlin`提供一流支持
|
||||
|
||||
2019 年 5 月 7 日，`Google `宣布 `Kotlin `编程语言现在是 `Android `应用开发者的首选语言（原来是`Java`）
|
||||
|
||||
`Kotlin `被设计为一种工业级的面向对象语言，并且是比 `Java `“更好的语言”，但仍然与 `Java `代码完全互操作，被称之为 Android 世界的`Swift`
|
||||
|
||||
优势：
|
||||
|
||||
- 简洁: 大大减少样板代码的数量。
|
||||
- 安全: 避免空指针异常等整个类的错误，旨在解决[十亿美元错误]([Null pointer - Wikipedia](https://en.wikipedia.org/wiki/Null_pointer#History))。
|
||||
- 互操作性: 充分利用 JVM、Android 和浏览器的现有库。
|
||||
- 工具友好: 可用任何 Java IDE 或者使用命令行构建。
|
||||
|
||||
|
||||
|
||||
所以，`Kotlin`是基于`Java`的衍生语言，并且比`Java`更高级，所以他优化了很多`Java`所容易出现的问题，如：大量模板代码、经常需要处理空指针异常、线程切换等问题。因为他更加高级所以也可以根据编译输出为其他语言，如：`JavaScript`等。由于`Kotlin`是基于`Java`完成的，所以他完全兼容`Java`，可以互相调用，这也就是说`Kotlin`可以兼容一些支持`Java`的库
|
||||
|
||||
根据`StatckOverflow`的数据：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
`Kotlin`整体的期望相对`Java`更高，但在使用量上依然有一段差距，但整体来看差距不是很大
|
||||
|
||||
并且目前`Java`中的常用库，如`Spring`、`Spring Boot`对于`Kotlin`也有原生支持：[创建使用 Kotlin 的 Spring Boot 项目 · Kotlin 官方文档 中文版 (kotlincn.net)](https://book.kotlincn.net/text/jvm-create-project-with-spring-boot.html)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
综上，在常规的`Java`后台项目中，`Kotlin`相对能提供更加简洁的语法，相对更少的代码量以及同等量级的社区支持，在综合方面可以和传统`Java`一较高低
|
||||
|
||||
|
||||
|
||||
### Vue和React、Nextjs如何选择
|
||||
|
||||
--------
|
||||
|
||||
`Vue` 在大前端时代，在国内市场可谓是大杀特杀，几乎以压倒性的优势占领着国内市场，并且随着 2020 年`Vue3`的发布，以及`Vite`的推出，其生态更加完善，基本是国内市场做前端的首选语言。
|
||||
|
||||
|
||||
|
||||
但和国内相悖的是，在`JetBrains`与`StackOverflow`在2023年的数据报告中，在前端方面数据，`Node`和`React`以压倒性优势领先其他语言
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
2023JavaScript趋势报告：
|
||||
|
||||
|
||||
|
||||
和国内不同的是，`React`在国外保持着惊人的活力
|
||||
|
||||
但也有很多反对`React`的声音，以及关于`React`辩论的文章，如：
|
||||
|
||||
[你因为 React 而忘记（或从来不知道）的事情 - Josh Collinsworth 博客](https://joshcollinsworth.com/blog/antiquated-react)
|
||||
|
||||
[React 的自我实现预言 - Josh Collinsworth 博客](https://joshcollinsworth.com/blog/self-fulfilling-prophecy-of-react)
|
||||
|
||||
[辛辣的 React 辩论秀 🌶️ （JS Party #244） (changelog.com)](https://changelog.com/jsparty/244)
|
||||
|
||||
|
||||
|
||||
如果各位有兴趣可以读原文，我这里为每篇文章简单的总结。
|
||||
|
||||
#### 第一篇：[你因为 React 而忘记（或从来不知道）的事情 - Josh Collinsworth 博客](https://joshcollinsworth.com/blog/antiquated-react)
|
||||
|
||||
>
|
||||
> 该文章也是被 `2023 JavaScript 行业调研报告` 所提到的文章，并且一些观点的确值得思考，但有的就一般了，为了准确传达原作者的意思，我这里会尽量中立的概括，也会引用部分原文进行对应部分内容的解释。
|
||||
|
||||
1. ##### 并不是所有好的事物都会流行。
|
||||
|
||||
> 回首往事，我意识到：我天真地相信，任何好东西都不可避免地会流行起来——因此，任何值得了解的东西最终都会自己出现。
|
||||
|
||||
|
||||
>
|
||||
> 作者开篇就提到了好的事物并不会自然的流行，自然而然的出现到你面前，也就说明了另一个意思：**出现在你面前的，流行起来的可能并不是最好的选择**
|
||||
|
||||
2. ##### `React`已经老化了
|
||||
|
||||
> React 从早期的框架游戏中受益匪浅;它设定了标准。但这在敏捷性和适应性方面存在严重缺陷。自 2013 年左右成立以来，React 做出的每一个决定都是另一层技术债务——它的新同时代人不受其约束。
|
||||
>
|
||||
> [再次引用亚历克斯的话](https://toot.cafe/@slightlyoff/110512849934452558)：
|
||||
>
|
||||
> > React 是 '13 技术，旨在 '08 约束。在 2023 年，它没有任何创新之处;事实上，这是现代获得函数式响应式前端编程的最慢方法......
|
||||
|
||||
3. ##### `React`是定制的，这使其在不同框架之间很难移植，几乎不和其他平台兼容
|
||||
|
||||
> 使用 React，每当我们需要一个模块、一个小部件或一个库来做一些特定的事情（旋转木马、地图、手风琴或其他任何东西）时，*它必须是 React 的东西*;一个普通的 Web 东西或一个普通的 JavaScript 东西是行不通的。React 的所有规则以及对组件生命周期状态和怪癖的处理意味着任何*没有*明确为 React 编写的可用包或库都可能无法工作。
|
||||
>
|
||||
> **React 训练我们，需要*专门为某个框架*构建东西。但这已经不是真的了，可以说永远不应该是这样。**
|
||||
|
||||
作者在这里举了个例子，通过框架之间的对比衬托`React`的独断专行
|
||||
|
||||
> [Preact Signals](https://preactjs.com/guide/v10/signals/) 就是一个非凡的例子：虽然它是为使用 Preact 而构建的，但它可以在*任何*框架中导入和使用，甚至可以在普通的 JavaScript 中使用。Web 组件也与几乎任何现代非 React 框架兼容。
|
||||
|
||||
4. ##### React 钩子实际上有点过时了
|
||||
|
||||
> 钩子是一种极好的模式，React 的普及值得称赞。但几乎所有其他框架都做得更好，规则更少，样板更少。
|
||||
|
||||
5. ##### `React`相对更加不智能
|
||||
|
||||
> 如今，框架足够聪明，可以处理这种事情，而不需要你握住他们的手并解释他们应该做什么。
|
||||
|
||||
"但React还是需要你做这些精细化管理"
|
||||
|
||||
6. ##### 服务器端渲染不再特别
|
||||
|
||||
> 几年前，曾经有一段时间，当涉及到服务器渲染的内容（主要是通过Next JS）时，React几乎是唯一的选择。人们理所当然地对 React 可以在服务器上以 HTML 形式呈现的想法感到兴奋，而不是在客户端上作为单页应用程序 （SPA） 呈现。速度和SEO的收益是不容忽视的，最初，其他框架需要一点时间才能赶上。不过选择更多框架都做到了。
|
||||
|
||||
7. ##### React 是由 Facebook 创建的，目的是解决 Facebook 独特的一系列问题
|
||||
|
||||
> 在 React 中使用表单是出了名的麻烦，因为每个用户击键都是一个两步过程：从输入中获取值;然后设置状态以匹配它（这反过来又不必要地重新渲染输入，以包含它已经完成的确切值，但与 React 状态同步）。当然，它通常太快而无法注意到，但这是很多额外的工作。
|
||||
>
|
||||
> 这就是为什么 React 的表单库激增的原因
|
||||
|
||||
8. ##### React 在性能上远远落后
|
||||
|
||||
> 在许多情况下，React 在性能方面（这里我指的是捆绑包大小和执行速度）落后 2 倍或更多。（捆绑包本身可以是 10 倍或更多。最新一轮[的 JS Web 框架基准测试](https://github.com/krausest/js-framework-benchmark)显示，React 的性能平均比 Solid 慢近 50%，比 Vue 慢 25%，比 Svelte 慢 40%，比 Preact 慢 35%。（其他框架在此特定测试中不可用。
|
||||
|
||||
9. ##### Svelte 是没有废话的 React
|
||||
|
||||
> Svelte 使用起来非常简单，相对容易学习（特别是如果你已经来自 React 世界，甚至语法通常也很相似），在几乎所有情况下都表现得更好，并且能够做任何 React 的事情，甚至更多
|
||||
|
||||
这也是作者留下的解决方案，并且根据作者本人所说，他本人的所有博客和网站都是有此完成.
|
||||
|
||||
|
||||
|
||||
#### 第二篇：[React 的自我实现预言 - Josh Collinsworth 博客](https://joshcollinsworth.com/blog/self-fulfilling-prophecy-of-react)
|
||||
|
||||
|
||||
>
|
||||
> 该篇文章是同一个作者在不同时期写的，本文完成时间更早，同样是对`React`的批评
|
||||
|
||||
1. ##### React 除了受欢迎之外，什么都不擅长。
|
||||
|
||||
> 让我在 React 和根本没有前端框架之间做出选择，并且给定任何足够大小或复杂度的项目，我很乐意接受 React，非常感谢。
|
||||
>
|
||||
> React 为其他框架正在做和已经做的很多事情奠定了基础。[Vue 3](https://vuejs.org/guide/introduction.html) 及其组合 API 显然受到了 React hooks 的启发。[Svelte](https://svelte.dev/) 的许多约定都来自 React。[Nuxt](https://nuxtjs.org/) 是我使用过并喜欢的 Vue 框架，它的许多想法（以及 75% 的名称）都来自 [Next](https://nextjs.org/)，一个 React 元框架。就此而言，整个基于组件的前端设计和开发模型的当前状态（哈）很大程度上归功于 React——尽管应该指出的是，其他人也帮助铺平了道路。
|
||||
>
|
||||
> **React 做了它擅长的事情，但它并没有比其他*框架做得更好。***
|
||||
|
||||
2. ##### 更多的社区和支持并不代表他是一个更好的选择
|
||||
|
||||
> 一个大的社区也可能是一个缺点，尤其是在所谓的“无主见”框架的情况下，比如 React。**这可能意味着有太多的套餐可供选择，以及太多不同的、相互竞争的意见，你必须在两者之间做出决定并采取立场。**
|
||||
|
||||
3. ##### 多年来，React 的满意度和兴趣一直在稳步下降，而其使用率却持平
|
||||
|
||||
> React 很容易成为最常用的前端框架，也是知名度最高的前端框架，但在今年的 [JS 现状调查结果](https://2021.stateofjs.com/en-US/libraries/front-end-frameworks/)中，React 在满意度方面落后于 Solid 和 Svelte。React 在兴趣方面也排在 Svelte、Solid 和 Vue 之后（对于 React 来说，兴趣*低于 50%）*。
|
||||
>
|
||||
> React 在 [StackOverflow 调查](https://insights.stackoverflow.com/survey/2021#technology-most-popular-technologies)中远远落后于 Svelte，也仅略微领先于 Vue。
|
||||
|
||||
4. ##### 为什么 React 会保持领先地位呢？
|
||||
|
||||
> “从来没有人因为选择 React 而被解雇”
|
||||
>
|
||||
> 这是安全的选择。它可能不是每个人的最爱，但不一定是。它可能也不会是任何人最不喜欢的。它会完成工作。
|
||||
|
||||
像`Vue`一样，因为市场需要所以企业招聘，因为企业招聘，所以更多人学习，同样的，因为会的人多，所以企业招聘。他们完成了各自的闭环，但**这个选择可能不是最明智的，但绝对是最安全的。**
|
||||
|
||||
|
||||
|
||||
#### 第三篇：[辛辣的 React 辩论秀 🌶️ （JS Party #244） (changelog.com)](https://changelog.com/jsparty/244)
|
||||
|
||||
|
||||
>
|
||||
> 本篇文章主要是关于是否应该放弃`React`而投身其他框架，以及`React`自身存在问题的讨论
|
||||
>
|
||||
> 本篇文章是对一个讨论节目的翻译版本，会有很多观点，本文只总结，不站队
|
||||
|
||||
##### 观点一：React赢被放弃
|
||||
|
||||
> - React 或多或少是任何给定项目的默认选择。它已经达到了临界质量，感觉就像是一切的安全默认值.
|
||||
>
|
||||
> - 从性能到捆绑包大小，到入职，再到复杂性、开发体验......一般来说，所有这些事情都是 React 本身并不能真正获胜的领域，在这些领域有更好的选择
|
||||
> - 当你缩小并查看大局时，你会意识到 React 在几乎每个给定的类别中都非常平庸，它真正擅长的唯一类别就是成为流行的东西。
|
||||
|
||||
##### 观点二：React有自己的难处，他不完美但已经做的很好了，并且也被很多人所接受
|
||||
|
||||
> - 当你流行时，你必须处理所有不同的情况。所以你不能只关注一件事而忽略其他。
|
||||
> - 如果我只关心绝对性能，我会发布静态 HTML。
|
||||
> - Stack Overflow 调查，我注意到 React 的满意度为 84%，高于 Vue，几乎是 Angular 的两倍，紧随 Svelte 之后，使用率更高。如果React被很多人使用，如果他不被大多数人满意，那他的满意度将会低很多，但事实上这并没有
|
||||
|
||||
##### 观点三：React更像一个仁慈的君主
|
||||
|
||||
> - 拥有一个几乎可以在任何地方使用的框架不是很好吗？我想要一个带有线条的 3D 旋转地球仪的库。你知道吗？你只需谷歌一下，它就在那里。你把它拉进来。很简单。生活很美好。（作为 2015 年框架战争的老兵，我只想说我们不想回到那个时代。每周都要面对一个新的框架，这让人筋疲力尽。）
|
||||
> - 如果我们要有一个统治框架，难道我们不希望它没有主见吗？所以 React 真的很好，因为它基本上只是一个带有最小状态管理解决方案的渲染库。有许多其他东西建立在 React 之上，这使得它与其他框架相当。所以即使你考虑元框架，也有很多流行的框架。
|
||||
> - 如果你了解 JavaScript，你几乎了解 React 的所有内容。他不会像Angular那样有很多新的“魔法”（这里指的是Angular引入的新的改变增加了学习成本，如管道，过滤器等）
|
||||
|
||||
|
||||
|
||||
##### 观点四：从公司架构思考问题
|
||||
|
||||
> React 的优势和我们遇到的摩擦都与它仍然由 Facebook 构建的事实有关，而 Facebook 的重点和优化选择都是为了解决 Facebook 所面临的问题。这些问题与许多公司在构建 JavaScript 应用程序时遇到的问题相当吻合，但一方面它们肯定是错的。
|
||||
>
|
||||
> 实际上，我认为你会在 Angular 中遇到一些相同的问题。Angular 仍然主要由 Google 想要什么和 Google 需要什么驱动。所以我认为，如果 Angular 达到这个水平——那么，早期的 Angular 确实很受欢迎，然后经历了很多这样的事情。
|
||||
>
|
||||
> 现在，如果你看看满意度，你会发现人们对 Angular 非常不满意，尽管有很多人在使用它。React 也可能会走这个老路……
|
||||
>
|
||||
> Vue 目前感觉更像是社区驱动。我觉得 Svelte 也在朝这个方向发展，尽管它们都是从仁慈独裁者的方式开始的。它们都拥抱了更广泛的社区，而不是只满足一家公司的需求
|
||||
|
||||
|
||||
|
||||
这几篇是一些影响力比较大的文章，相对来说观点已经比较全面了，大致分为以下几点：
|
||||
|
||||
1. React 因为时代原因已经有些过时了，因为使用的人很多，所以他每一次新功能的增加都将非常谨慎像现在的Java一样，虽然版本号一路突飞猛进，但是变化依然不大
|
||||
2. React 的除了流行外别无优点，整体的性能，包大小，等都不够拔
|
||||
|
||||
但React也有其自己的优点：
|
||||
|
||||
1. 最强大的社区支持，你几乎能找到你想要的所有库
|
||||
2. React不是一个框架，而是一个库，你多了解 JavaScript 就有多了解 React。他可以让你进行最大限度的定制
|
||||
|
||||
|
||||
|
||||
|
||||
### TypeScript 应该放弃吗
|
||||
|
||||
--------
|
||||
|
||||
抛出这个问题主要基于22年和23年发生的一些事件：
|
||||
|
||||
<img src="1001%20-%20%E6%88%91%E4%BB%AC%E5%BA%94%E8%AF%A5%E9%80%89%E6%8B%A9%E4%BB%80%E4%B9%88%E5%BC%80%E5%8F%91%E8%AF%AD%E8%A8%80.assets/up-58c4155f83bbd826f4bb0ec1ab8d1e32ccd-1719469395020-15-1719469397190-17.png" alt="img" style="zoom:67%;" />
|
||||
|
||||
|
||||
|
||||
<img src="1001%20-%20%E6%88%91%E4%BB%AC%E5%BA%94%E8%AF%A5%E9%80%89%E6%8B%A9%E4%BB%80%E4%B9%88%E5%BC%80%E5%8F%91%E8%AF%AD%E8%A8%80.assets/eed5a2dd0f71b8b4790a1b20c708416c-1719469475131-21.png" alt="图片" />
|
||||
|
||||
并且Svelte 不是第一个放弃 TypeScript 的前端框架。早在 2020 年，Deno 就迁移了一部分內部 TypeScript 代码到 JavaScript，以减少构建时间。
|
||||
|
||||
|
||||
|
||||
并且这些大牛放弃 TypeScript 似乎还加快了工作进度，但这个选择是否应该被普通开发者所选择？
|
||||
|
||||
搜了很多文章，但是大部分都在将一些很正确的废话，目前来看只有下面两片有参考价值。
|
||||
|
||||
##### 第一篇：[Turbo 8 正在放弃 TypeScript (hey.com)](https://world.hey.com/dhh/turbo-8-is-dropping-typescript-70165c01)
|
||||
|
||||
|
||||
>
|
||||
> 这是原文，正式这篇文章，引来了众多讨论
|
||||
|
||||
文章的主要观点如下：
|
||||
|
||||
> TypeScript 只是妨碍了我。不仅因为它需要显式的编译步骤，还因为它用类型体操污染了代码
|
||||
|
||||
—— 多余类型判断只会降低效率
|
||||
|
||||
文章没有多长，几乎没有太多参考价值，但毕竟是原文，还是搬过来比较好。
|
||||
|
||||
并且对于这篇文章，Reddit的评论区也是活力十足
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
并且在知乎对于这个问题的评价更加激进：
|
||||
|
||||
|
||||
|
||||
以下是文字版本：
|
||||
|
||||
> 前端届盛产大牛，整点别人看不懂的代码，硬说函数式然后猛劲宣传就能当大牛。
|
||||
>
|
||||
> 搞计算机其实有一点不好，就是你以为有些应该不在世的大师他都活着呢。
|
||||
>
|
||||
> 算法分析之父高德纳还在呢。
|
||||
>
|
||||
> WindowsNT内核之父David Cuttler也还在呢。
|
||||
>
|
||||
> Linux内核之父Linus还到处喷人呢。
|
||||
>
|
||||
> GUI和面向对象之父Allen Kay也还在呢。
|
||||
>
|
||||
> Pascal总架构师，Delphi和C#之父，编程语言届的传奇**Anders Hejlsberg**也还在努力工作呢。
|
||||
>
|
||||
> 我不明白某些在社区当网红的不入流货色是怎么敢被封为大牛还大放厥词的。
|
||||
>
|
||||
> 对了，TypeScript就是Anders搞的。
|
||||
|
||||
|
||||
|
||||
无论是知乎还是Reddit的讨论都是相对激进，并拳拳到肉那种，只顾着输出情绪了。不过总结起来大致为以下两个观点：
|
||||
|
||||
1. Turbo 8 并不是什么知名项目，没人在意他是否放弃 TypeScript
|
||||
2. Turbo 8 的作者（也是文章作者），经常写类似的文章来唱反调
|
||||
3. 文章除了说明了类型让他更加麻烦了，并且有提出其他有力依据，所以被Reddit评论区狂怼
|
||||
4. 这个大牛是虚假宣传的，为了博眼球臆造出来的，而那些真正的大牛创造了TypeScript
|
||||
|
||||
|
||||
|
||||
当然**无意义的情绪输出不能解决任何问题**，所以也有下面这个文章通过多个方面来讨论为什么那些社区项目会放弃TypeScript
|
||||
|
||||
|
||||
|
||||
##### 第二篇：[“根本不需要 TypeScript，JS + JSDoc 够了”，大佬说我想多了](https://my.oschina.net/u/6852546/blog/10114672)
|
||||
|
||||
文章的主要观点如下：
|
||||
|
||||
> 某些场景下，写 TypeScript 会带来一些额外成本。一些开源库的源码，核心逻辑可能就几十行，但为了实现准确的类型提示，写出来的类型体操反而远远多于核心源码，孰是孰非对于不同的开发者有不同的准绳，需要找到其中的平衡点。
|
||||
|
||||
—— 对于特定场景，TypeScript 确实更麻烦了
|
||||
|
||||
> 使用了 TypeScript 的项目改回使用 JavaScript 是很少见的，更多的项目是从 JavaScript 升级到 TypeScript。TypeScript 完善了 JavaScript 的类型系统，使得代码的可维护性更高了.
|
||||
|
||||
—— 相对来说，TypeScript 相对于 JavaScript 是更加受欢迎的，并且被更多项目所接受
|
||||
|
||||
> **框架和类库的开发者，往往需要考虑到很多 edge case**，在这种情况下，编写完善的类型是一件很费心力的事，代码量会多了不少，从而会导致维护成本的增加。
|
||||
|
||||
—— 放弃 TypeScript 的更多是那些公共仓库的维护者，而他们需要考虑所有有可能出现的情况，会有非常多的边缘判断来减少异常，这也造成了如果使用 TypeScript反而会更麻烦
|
||||
|
||||
> TypeScript 的成功无需质疑，已经有无数的项目证明了它的成功。开发者并没有 “嫌弃” TypeScript，只是认为并不是所有项目都适合使用 TypeScript。
|
||||
|
||||
> **有人认为，** **TypeScript** **的出现是因为一般人驾驭不了** **JavaScript** **，有人则觉得 “水平越差的人越喜欢自由”，你怎么看？这两个语言的选择跟程序员的水平有关吗？**
|
||||
>
|
||||
> - 平时可没少见有同学吐槽，**好好的 TypeScript 项目，被人提交了一堆 Any**。也见过很多吐槽接手了一个 TypeScript 仓库，要硬着头皮看一大堆类型定义，搞清楚这些奇奇怪怪的类型是如何工作的。我觉得语言的选择主要看团队的工程化和规范化程度，过犹不及。如果一个 TypeScript 类库写了一大堆类型，但却连一个单测都没有，那我觉得它是不合格的。
|
||||
> - JavaScript 和 TypeScript 不能用来衡量程序员的水平。对于简单的项目或者个人项目而言，JavaScript 可能更加轻量和灵活，但对于需要大团队协作，复杂的项目而言，TypeScript 的类型系统就可以带来更好的代码维护性和可靠性了。
|
||||
|
||||
|
||||
|
||||
该文章相对来说理性了很多，通过一些采访来尽量还原更加客观的事实，并且对于 TypeScript 的选择相对来说没有那么难决断，那些仓库的作者因为繁琐的 **edge case** 放弃了 TS，但这并不代表他没有一点自己的用武之地，在常规的项目中，尤其是大型的多人合作项目中，TS也会是优先的选择。
|
||||
|
||||
并且无论是TS还是JS都能做出很好的产品，二者没有高低贵贱之分，如果一个TS项目写满了 `Any` 那不如直接切换为 JS 反而在某种程度还更能节约代码量了
|
||||
|
||||
|
||||
|
||||
### 为什么不使用跨平台框架
|
||||
|
||||
##### 跨平台还是原原生？
|
||||
|
||||
如果我作为一个项目经理或技术总监，我现在收到了上级的要求，要我的团队做一款茶品出来，要有Web端，Android端，IOS端，外加微信小程序，京东小程序，支付宝小程序。最好再带上桌面端（Exe程序），并且最好在尽量短的时间内完成。
|
||||
|
||||
这种情况下我绝对会选择一款跨平台的框架，有很多框架可以选择比如 Flutter 、Koltin、React Native 他们的初衷就是为了一端多用而诞生，为了兼容小程序可能会使用 Uniapp 选择会非常多。
|
||||
|
||||
但是这完全是为了做产品做做出的选择，为了满足快速的迭代，为了最快的满足最低要求做出的抉择，并且这更像是为了满足那些资本家更快占领市场所做的选择，无论如何，这绝不应该是第一选择。
|
||||
|
||||
|
||||
|
||||
##### 为什么反对跨平台
|
||||
|
||||
1. **跨平台永远落后**
|
||||
|
||||
比如在Android的原生开发中，如果想要使用官方提供的新推出的组件库，直接引入就好了，并且官方提供支持，如果是跨平台的话，则需要等待平台支持后才能使用，并且使用往往会更加麻烦
|
||||
|
||||
2. **无法使用原生的设计思路**
|
||||
|
||||
对于不同的平台，设计思路是完全不同的，比如Web端，Android端，IOS端 。
|
||||
|
||||
> Web端更考虑的时候灵活和在不同页面的统一表现，往往是为了方便用户而出现的，并且得益于浏览器的统一实现，任何设备都可以随时随地访问
|
||||
>
|
||||
> Android 端更多的是考虑安全性 、隐私性，系统提供的组件更加的风格化，统一化，并且可以用到更多的系统特性，如GPS，相机，本地文件等可以
|
||||
>
|
||||
> IOS端和Android类似，但是整体更加统一，动画的一致性效果也是最好的，并且同样可以更方便的访问相机、GPS、本地文件等内容
|
||||
|
||||
他们三者都有各自的特点，没有任何一端的设计语言可以完全照搬照抄，如果跨平台，那么他几乎要放弃所有的优化，抛弃除了方便之外的所有优势，并且也更难实现组件风格统一。
|
||||
|
||||
3. **兼容性**
|
||||
|
||||
如果是同一平台，夸设备主要包括不同设备和不同软件版本的兼容，但是往往针对这些，官方都会给出一些适配方式或替代方案
|
||||
|
||||
但是对于跨平台来说，几乎会将设备内容限制在一个固定的范围，并且很难向老的设备兼容，因为这意味着更多的投入，甚至压根无法完成
|
||||
|
||||
4. **长期维护和扩展**
|
||||
|
||||
这一点毋庸置疑，一定是原生会有更好的兼容和适配。
|
||||
|
||||
5. **一致的展示效果**
|
||||
|
||||
魔鬼在于细节。iOS 和 Android 等本机平台已经发展了很长时间。
|
||||
|
||||
成熟的工具已经解决了新框架甚至没有遇到的问题。复杂性的假象实际上是解决困难用例的成熟度。
|
||||
|
||||
> 不同的平台的语言有各自的设计思路，并且经过十几年的发展相对更加稳固，体会不一样的平台，反而能体验更多不同的设计思路和设计方式。
|
||||
|
||||
针对跨平台框架的讨论国内和国外的开发者都有比较多的文章可以查到
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#### 为什么要做一个自己的网站
|
||||
|
||||
无论是在公司还是在原先的项目中，无论是谁都很难做到全栈，但是现在几乎所有的环节都已经打通，不为他人而工作，做一个自己的东西出来，可以熟悉各端的开发方式，也能在项目中加入一些功能，自己访问也更加方便，并且因为是自己的东西，所以所有的在网上或者任何平台看到的任何好的设计和内容都可以直接“借鉴”到网站中。
|
||||
|
||||
这样也不至于工作了多年，为公司做了很多很好的东西，最棒的思路都用到了公司，反而没有做一个自己想做的东西。
|
||||
|
||||
并且真的有一天因为各种原因离职了，简历的呈现方式绝对不是 PDF 了，完全可以是一个网址。
|
||||
|
||||
|
||||
|
||||
#### 它的最终样子会是如何
|
||||
|
||||
我也无法设想他以后的发展，就眼前来说，会先依据**网络论坛**作为一个基础，来先做出基础功能，这个论坛类似于豆瓣的小组，百度的贴吧，但要做的并不是和他们这些大公司竞争，而是做一个平台出来，只是一小部分人使用，如果能有更高的人气和注册量当然更好。依托这个网站平台，可以添加更多想做的东西出来，比如博客，以及在其他任何网页上所有看起来不错的CSS效果等
|
||||
|
||||
并且他可以做各种想做的东西，任何其他类型的网站也都可以在该平台完成
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
> 本文参考的文章如下：
|
||||
> [JetBrains2023行业状况调研](https://www.jetbrains.com/zh-cn/)
|
||||
>
|
||||
> [StackOverflow2023行业调查问卷](https://survey.stackoverflow.co/2023/)
|
||||
>
|
||||
> [你因为 React 而忘记（或从来不知道）的事情 - Josh Collinsworth 博客](https://joshcollinsworth.com/blog/antiquated-react)
|
||||
>
|
||||
> [React 的自我实现预言 - Josh Collinsworth 博客](https://joshcollinsworth.com/blog/self-fulfilling-prophecy-of-react)
|
||||
>
|
||||
> [辛辣的 React 辩论秀 🌶️ （JS Party #244） (changelog.com)](https://changelog.com/jsparty/244)
|
||||
Reference in new issue
Block a user