V2EX › 3dwelcome 的所有回复 › 第 42 页 / 共 155 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 38 39 40 41 42 43 44 45 46 47 ... 155

❮

❯

2022-01-05 13:25:19 +08:00

回复了 3dwelcome 创建的主题 › 前端开发 › 有没有人觉得选择前端职业，很难成长为一个真正的程序员？

@dabaoziwy 学算法是为了能学以致用。实际项目里又用不上，过个半年就忘的差不多了，很难形成良性循环的技术积累。

想把个人技术转换成生产力，在前端是一件比较困难的事情。

基本上自己能做到的，别人也能，拉不开明显差距。

2022-01-05 12:58:00 +08:00

回复了 3dwelcome 创建的主题 › 前端开发 › 有没有人觉得选择前端职业，很难成长为一个真正的程序员？

@DOLLOR 不是歧视，是焦虑，怕以后被淘汰。

前端没有有效的技术屏障，可以阻止后浪来卷。

天天写一大堆组件库，也没提升多少竞争力，因为开源组件库也实在太多了。

2022-01-05 12:47:37 +08:00

回复了 3dwelcome 创建的主题 › 前端开发 › 有没有人觉得选择前端职业，很难成长为一个真正的程序员？

@hpoenixf 前端的刚需，就是给用户呈现出一个漂亮精致优雅的交互界面。

理科码农画画都一般，拼不过美术学院的妹子。

缺了核心竞争力，那些页面加载技术，就只是很弱的加分项。后浪真心来卷，这点小技术是挡不住的。

2022-01-05 12:42:40 +08:00

回复了 3dwelcome 创建的主题 › 前端开发 › 有没有人觉得选择前端职业，很难成长为一个真正的程序员？

@kop1989 “任何你用 java 、C#、C++能实现的数据算法，js 也都能实现。”

能用 JS 实现的，最终都会用 JS 来写，这句只是理论说法。

事实上越来越多的复杂算法，开始抛弃 JS ，改用其他语言用 WASM 运行在浏览器里。

2022-01-05 12:15:45 +08:00

回复了 3dwelcome 创建的主题 › 前端开发 › 有没有人觉得选择前端职业，很难成长为一个真正的程序员？

@stoneabc CRUD 至少是代码优先，后端往深了，可以研究分布式，高并发，也有技术含量的。

前端不一样，美术设计要高于代码技术。

2022-01-05 12:10:01 +08:00

回复了 3dwelcome 创建的主题 › 前端开发 › 有没有人觉得选择前端职业，很难成长为一个真正的程序员？

@kop1989 游戏开发，哪怕再小的游戏，都是需要设计数据结构的。

而前端偏偏故意去弱化数据结构，一切都向 JSON API 看齐。一切算法都先在 npm 里找，抹杀了个人创造力。

也看到过前端很强的 JS 算法，可惜那些都是 side project ，在正常的职业道路上，很难接触到这种项目。

2022-01-05 12:01:41 +08:00

回复了 3dwelcome 创建的主题 › 前端开发 › 有没有人觉得选择前端职业，很难成长为一个真正的程序员？

@shintendo 我只是觉得理科当前端，发挥不了堆代码特长。反而美术好的艺术科，能把前端设计美如画。

2022-01-05 11:34:19 +08:00

回复了 111qqz 创建的主题 › C++ › 为什么 gcc5 下的 new operator 可以得到 32 byte 对齐的地址(在 x86-64 机器上)

gcc4.9 以前一直有对齐关键字，叫__declspec(align(32))，这是很早以前就支持的。

alignnas 这个应该是新编译器才支持的。

2022-01-05 11:22:37 +08:00

回复了 supuwoerc 创建的主题 › 程序员 › 用进废退同样深刻影响编程

听着歌，写着前端的码农飘过。

本来程序员就是一个很费脑子的职业，只不过前端写太多了，会产生一种写代码，只需要积累组件库数量的错觉。

老外有句话，多写点底层，有助于提升码农的灵魂。

2022-01-05 10:57:30 +08:00

回复了 111qqz 创建的主题 › C++ › 为什么 gcc5 下的 new operator 可以得到 32 byte 对齐的地址(在 x86-64 机器上)

不懂，你代码里写了 alignas(32)关键字，那就是期望 32 位内存对齐啊。

把关键字去掉，就不是这个结果了。

当然那现在内存不值钱，多浪费点空间没什么。然而对齐了，指令性能和移动端的可移植性，都能得到提升。

2022-01-05 10:24:36 +08:00

回复了 jhqz103 创建的主题 › 程序员 › 关于客户端的数据存储

web 官方默认储存方案是 indexedDB ，但你又不是 web ，只是一个普通的客户端版本，无论想怎么存都可以啊。

以前都流行 WebSQL, 也就是 sqlite ，现在风向变了，chrome 完全偏爱 KeyValue 数据库。

2022-01-05 10:19:36 +08:00

回复了 LuciusChen 创建的主题 › JavaScript › 这种业务场景有没有更优雅的方式？

"前端调用后台代码就需要在对应的 code 分支内重复调用该接口。"

我觉得业务逻辑没什么问题，但是你前端重复请求那就有问题了。

可以考虑把前端的几次请求，打包合并成一个后发送，然后按照多个命令的形式来解析。

2021-12-30 18:12:51 +08:00

回复了 rimworld 创建的主题 › 求职 › [想求职][webgis]自学的 webgis，想请各位前辈给点建议

wasm 就是用另外一种语言，来代替 JS 处理图形中各种坐标数据。

js 里想要精确处理二进制的 int/float/double ，写各种图形相交查询等算法，不是不能实现，而是一件吃力不讨好的事情。

浏览器语言融合技术，应该就是以后 WebGIS 开发里，偏重客户端的核心技术了。

2021-12-30 16:57:50 +08:00

回复了 rimworld 创建的主题 › 求职 › [想求职][webgis]自学的 webgis，想请各位前辈给点建议

我是觉得楼主做的挺好，VUE 源代码清晰，热力图也好看。楼上那些高要求，只要工作年限上去，水平自然就上去了。

我最近也对 webgis 有点兴趣，以前有两个痛点，一是用 js 处理二进制的大数据不太给力，二是 webgis 开发思，维始终停留在服务器提供数据，客户端拉取数据上。网络请求次数太多，用户体验就会下降。

现在用了 webasm 技术后，这两个问题都解决了。

测试过普通 PC 浏览器，客户端纯内存加载可以到很高的上限，而普通地图数据，也就一两百兆左右。以前需要服务器协助的事情，现在客户端都能本地处理。

2021-12-30 14:13:06 +08:00

回复了 rv54ntjwfm3ug8 创建的主题 › 问与答 › 为什么这么多端到端加密的开源项目桌面客户端 UI 都用 Electron 而不是 Qt 编写？

对我来说没压力。但是对大部分人来说，你把 Web UI 搬到桌面没问题，但要把 QT UI 反向搬到浏览器里，还是有点技术难度的。

能用 JS 写的，最终都会用 JS 写。字节团队说，国内有 1/5 的开发人员，都是前端 JS/TS 技术向。

要把一个技术学好不容易，Web 写的越久，积累越多，想掉头就越难。可能很多时候 Electron 并不是最佳选择，但是开发者熟悉啊。

2021-12-29 09:56:53 +08:00

回复了 revalue 创建的主题 › 前端开发 › 做前端真累：写给其他职能看的前端述职 (吐槽)

@murmur

前端又不只开发移动端 APP ，flutter 做 web 目前还非常不完善。

自渲染早在 flash 时代就火过一次，可还是打不过浏览器的原生组件。

ReactNative 和 flutter ，谁能笑到最后，还不知道呢。

2021-12-29 09:42:25 +08:00

回复了 revalue 创建的主题 › 前端开发 › 做前端真累：写给其他职能看的前端述职 (吐槽)

@iamv2er
“我见过两家公司 vue 写了的，居然要用 react 重写。当时想，是没事干了硬给自己创造需求吗？”

VUE 设计再方便，想找好工作还是要学 React ，都已经达成业内共识了。

没办法，这个前端世界，就是这个游戏规则。

2021-12-29 09:38:06 +08:00

回复了 revalue 创建的主题 › 前端开发 › 做前端真累：写给其他职能看的前端述职 (吐槽)

css 分 flex 前时代和 flex 后时代，不用 display:flex 调个垂直居中，那真是各种 hack ，心力交瘁。

前端最大的问题，应该不是如何把功能实现出来，而是复杂应用中，如何把日益膨胀的代码库给维护好。

如果不借鉴一些别的语言架构，那只有不断的实践-》推倒重构。

1 ... 38 39 40 41 42 43 44 45 46 47 ... 155

❮

❯