iOS和Android市场萎靡: 一方面是公司挥舞着大把钞票招不到靠谱的

作者:admin 来源:未知 点击数: 发布时间:2020年10月11日

  目前大家都在炒冷饭,pwa,ssr,amp,webcomponent,甚至是graphql,毫无新意,没啥劲,散了吧。如果发非要掰扯,我推荐node搞区块链智能合约truffle,node做ai的tfjs,就算风口过了也能学点东西,万一上风口呢?

  跨平台需求极其强烈: 这个也是中国特色,除了传统的三大平台之外,国内公司喜欢极了造各种护城河,什么微信小程序、支付宝小程序、安卓快应用,在一个成熟的无线团队中起码要做 iOS、Android、H5、支付宝小程序、微信小程序、安卓快应用这六个平台,带来的问题就是人员需求增多,潜在的问题就是管理问题、招人问题、成本问题,如果有一门统一六端的技术不火都难。

  编译原理: 编译原理其实真的是不难(指的是前端部分,后端大佬略过),更何况已经有 Babel 这种成熟的工具了,跨平台技术的开发根本离不开编译原理,哪怕之前京东搞得哪个 Taro 也都用了 Babel 把 JSX 转义了,更何况 Facebook 造的reasonml,所以编译原理是逃不掉的.

  这里我们很容易犯的一个错误是思维局限在技术里,总是从技术的角度去找解决办法。比如满足业务迭代的需求,我们不光可以提升开发效率,我们还可以去招外包嘛。再比如一个业务花费了大量的人力去做,但用户量还是做不起来,这时候把业务线砍掉也许才是最好的解决办法。所以做决策之前还要全面分析一下利弊才行,有些问题也许用非技术的方法解决反而更好。

  AMP或者MIP,需要借助相关搜索优化的可以考虑,或者搞SEO的公司值得跟进下。

  7. 一个跟前端不太契合的点。别问我Deno怎么样。Go会不断挤压Node,这是现实。

  如果说团队做的是“基于WebGL Shader的研究,主要用于像素流场实现动态梵高向日葵名画”,目前进度完成了35%,并遇到了XXX若干问题正在解决,领导会觉得你吃饱了没事做。当时我就是在学习相关的知识,还看了Matlab关于流场的教程、基于能量场的寻路知识等,领导觉得我工作不饱和,需要加工作量。

  对于刚孵化的内部产品来说,我们可能要满足公司快速迭代的要求,这事开发效率要比页面性能的优先级要高。对于功能成熟、用户量大的产品来说,可能页面性能要比开发效率的优先级要高。

  跨平台技术逐渐成熟:前几天 Airbnb 放弃 RN 的事件让客户端工程师高兴了一把,其实我想说国内的趋势是越来越多的公司开始用 RN 这种技术,湾区那边跟国内完全不一样,即使 Facebook 内部用 RN 的也是很小众的团队,其实你仔细看 Airbnb 那五篇文章,放弃的理由在国内公司看来是完全可以忍受的,就比如类型系统缺陷,且不说Facebook 搞得那个 reasonml可以无压力解决这个问题,国内公司根本不在乎类型系统,猛糙快才是硬道理,再比如首屏的问题,在国内根本不存在这个问题,反正启动阶段先给你5s 首屏广告,现在国内有几个APP没首屏广告的?反而是现在 RN 团队要在年底重写完 RN 的底层,据悉会大量解决掉 Airbnb 文章中提到的问题,要知道 RN 现在还在0.5x 版本,1.0版本还没发布,届时一个成熟的 RN 在国内被越来越多的人追捧是可以预见的。

  1、客户端宿主技术:比如公众号,小程序,RN,Weex什么的,无它(打工必备),其实就是跟进比如小程序的各种API变更、开放了什么权限,以及各种一处编写到处调试(实时跟进宿主环境的变更,属于情怀,与技术无关);

  今天我最头疼的是,被三大框架绑定,喜忧参半,既想用(或者说不得不用),又希望保留足够的灵活性。

  工程化方面,可围绕以上的前端、后端技术,打造自己的一套开发、运维体系。在未来一两年小程序集中增长爆发的阶段,能比较从容地应对小程序的业务开发。

  对于新技术,不上是等死,上了是找死。目前在找死的路上努力的找一种更舒服的死法。

  学习后端的技术和理念,理解后端的约束和限制。在前后端分离架构下,前端和后端各有各的优势和劣势,也各有各的期望和关切,不要指望后端一味配合你,那样做甚至对整个团队都有害。如果你都不理解后端,就别期望你们能良好协作。

  1、webpack一定要会,一定要会,最好精通,搞定webpack,80%前端工程问题都没有问题了。

  PWA 可以考虑跟进了,随着Safari的11.3版本支持PWA,PWA的覆盖率足够了,它的特性可以考虑结合自身业务场景做一些优化了,特别适合自己业务在多个别的公司移动APP里面高频访问的时候,比如 公众号之类的。

  跨平台工具开发者: 国内奇葩的六大平台需求,会有不少团队耐不住寂寞造跨六端的轮子,京东的 Taro 用的 Rn 作为 native 平台,肯定也会有基于WEEX或者Flutter的,前提就是要懂框架开发、要懂parser、懂几大平台的技术。

  5. 大前端我一直认为是一种美好提法,在业务和技术双重碎片化的环境下,各端/多端的技能仍是具备隔离性和差异化,不容易融合,分工仍细化,管理上也有难度。但随着小程序和跨平台方案的风靡或层出不穷,假以时日在大前端方面的趋势将逐渐有集中收敛迹象,但远不会完全收敛。

  所有这些目标都必须是符合SMART的,也就是符合目标管理原则,其中最重要的一点就是可量化,这样我们通过达成这些目标来为业务增长做贡献。这一步大家最常遇到的问题就是,老大没给自己什么目标。这时候你就需要站在他的位置上来给自己设立目标,然后再给老大看这个目标是否 ok。

  跨平台工程师: 招 RN、WEEX、Flutter的公司会越来越多,要求也不会低,起码前端+一种 native 技术,当然薪资应该也不错.

  什么叫做从业务出发?一般公司每年都会公布年度目标,然后每个部门按照自己的职能逐层向下分解。到前端技术部这边一般的目标就是下面几类:

  谢邀! 其他人已经说了很多了,我来说一下有关小程序(轻应用)这块的技术规划。

  2、Node:数据库、分布式、操作系统基础,微服务、容器等各种运维技术(长期不过时),安全、密码学、区块链……

  4. 个人在经历了TypeScript的热情之余,也在反思TS的问题,其在OOP方面的特异点,我觉得设计做得并不够好,仍是过于松散不够严谨。比如接口设计。而不够严谨,其实带来了混乱和复杂度。从这点,ES6/7显然在折中方面更灵活更让我满意。

  这个主要是答主自己在沉淀的一个方向,由于网页/H5等前端场景在生活的覆盖越来越大,感觉APM这个方向也变得尤为重要,APM的内容必然会反作用于开发效率、自动化测试等方向。

  跨平台方向,无论是web这边小程序、H5结合,还是Naive的IOS、Android结合,甚至这4个都一次性搞定。

  2. 多做一些跨平台项目: 我们还有一款移动端产品正在由纯前端团队开发,一方面是锻炼团队对跨平台技术的运用,另一方面是展示团队的能力为以后合并掉移动端团队增加砝码.

  为了使其成为二维的网格容器,我们需要定义列和行。让我们创建3列和2行。我们将使用grid-template-row和grid-template-column属性。

  当我们有了业务目标、业务现状、技术现状、现存重要的问题之后,我们就可以思考怎么去解决了。

  技术规划离不开对未来的趋势判断,技术规划要结合趋势,如果你现在要做 Flash 开发的技术规划那一定是脑子出问题了,所以我们要先判断下趋势.

  Node毕竟是我大前端的一个后端利器,因此基于Node的发展,多多少少可以在该领域找到一些新的技术创新点,例如是一些新的Web框架、新的服务中间件、或者如果利用node实现中台化的优化,都还是多少有点搞头的;

  一个全面掌控级别的前端领头人,比较理想的薪资是综合年收入税前120到150万。

  AR、VR:这两个技术在 native 尚且还没成熟,更别提中国目前绝大部分手机还是中低端机,经不起 AR 这种密集计算的折腾,就更别提苹果对 WebRTC那可怜的支持程度了,再加上 Webassembly 本身就不成熟,想考 js 玩 AR 基本不可能,这需要硬件算力、厂商支持、技术成熟等一系列要求,先等个三五年吧.

  这里就是技术规划最后的一步了,就是要设立一个可量化的检查节点。如果你是一个团队负责人的话,这些里程碑的量化目标就要拿给团队里的同学做进一步分解了。如果你是基层研发,这些里程碑就需要自己去实现了。

  2. 工程化。这点很重要,平时悠哉悠哉的时候不感觉,出了问题了,手忙脚乱了,就能发现工程化质量好坏影响很大。

  我们是为公司业务服务的技术团队,所以做任何事情都要从业务出发。这是做技术规划第一件要做的事情,毕竟我们所有人的工资都要业务增长去买单的。上来先想要做 XXX 技术,要优化 XXX 的话,方向就错了。

  3、三大框架,一定要先学angular,那样你才知道什么叫前端框架!你才知道ts有多重要,rxjs的牛逼之处等等等,angular是唯一真正意义上的前端框架!

  不知道你发现没有,我们只在页面上看到 3×2 的 grid(网格),而我们定义的是 3×3 的 grid(网格)。这是因为我们只有 6 个 items(子元素) 来填满这个网格。如果我们再加3个 items(子元素),那么最后一行也会被填满。要定位和调整 items(子元素) 大小,我们将使用grid-column和grid-row属性来设置:.item1 {grid-column-start: 1;grid-column-end: 4;}我们在这里要做的是,我们希望 item1 占据从第一条网格线开始,到第四条网格线结束。换句话说,它将独立占据整行。 以下是在屏幕上显示的内容:

  Web App Manifest 是为了解决用户留存问题而诞生的,它是一个外链的 JSON 文件,在这个文件中,像浏览器暴露了站点的名称,地址,图标等等元数据。在浏览器中通过 引入这个 JSON 文件,浏览器识别到这个文件的存在,会根据自己的机制决定是否弹出添加到桌面对话框,并在桌面上生成一个应用的图标,通过点击桌面图标进入应用具有沉浸式的体验,全屏显示,没有浏览器地址栏,并且还会自动添加应用启动画面。

  关于小程序,端方面其实已经有些尝试了,早期的如wepy,到新近更为成熟,对接团队技术栈美团的 mpvue 还有京东的 taro。不近将来,我推断可能还要出现基于小程序语法的框架出现。

  选一个一流的 IDE,把它用到滚瓜烂熟,探索、试验每一个特性,记住高频操作的快捷键,体验它在你开发时的加速作用。在工程化开发中,IDE 能给你带来的价值不可估量。推荐:收费的用 WebStorm/IntelliJ 系列,免费的用 vscode。

  HTMl5.2新的版本出现了一个有意思的标签,那就是对话窗或窗口,也就是dialog,其基本用法如下:

  Push Notification 其实是两个 API 的结合, Notification API 和 Push API 。 Notification API 提供了开发者可以给用户发送通知的能力,包括申请显示通知权限,发起通知,以及定制通知的类型等等。 Push API,则是让服务器能够向用户发送离线消息,即使用户当前并没有打开你的页面,甚至没有打开浏览器。

  如果遇到外行的领导,来关心团队的最近研究成果。如果回答的是“基于XX新平台的技术研发,我们会在一周后成果上线,这将会是国内最早的该平台项目。”,目前完成度100%,外行领导会大悦。就像跳一跳小游戏刚出来的时候,我用three.js半天写了一个跳一跳H5小游戏,领导非常肯定我工作之余的学习态度。

  大家都知道ssr因事件/timer和过长的响应时间而无法有很高qps(够用,优化难),而且对api聚合处理也不是很爽。更尴尬的是ssr下做前后端分离蛋疼,不做也蛋疼,到底让人咋样吗?

  图像方向,其实不仅仅是图像,感觉一些实时视频,语音最近其实都有不错的发展,只是场景的固定和渗透性的不足,很多时候我们一般的开发者用不上,或者没有去了解而已,前端是视觉和交互的奠基,因此图形图像方向的发展还是有的,这方面的优化,我觉得是让前端往客户端方向找到更多的突破口;

  iOS和Android市场萎靡: 一方面是公司挥舞着大把钞票招不到靠谱的客户端工程师,一方面是各种 IOS/Android 没人要了的人才市场,归根到底是市场萎靡了,本属于 native 的蛋糕被 hybrid、rn、weex、xx 小程序、快应用等等切走了一大块,导致写着各种业务代码的中低级工程师的饭碗被前端们抢了去,高级的 native 工程师开发着底层容器和架构,这个趋势从培训班的宣传程度和综合技术社区客户端开发的冷清可以很明显的看出来,一向崇尚猛糙快的中国互联网市场容不下 native 工程师,湾区那边要好很多,客户端工程师还是很滋润的,但是国情真的不同。

  这些基础知识,可能可以用30年。我在想这也是为什么日本程序员可以写到50多岁,中国程序员有35岁门槛的原因。一个“Lou的伪3D道路”教程,从90年代到现在的canvas时代,它的数学知识依然没有过时,对新人具有极大的启发意义。现在很多前端从业人员,在选择追热点拿高薪还是往深挖掘提高上面,更多人是向钱和热点发展。

  单看这篇报道,预计许多中小企业,都会围绕微信的生态,打造与自己服务相关的一款小程序。腾讯内部的许多部门,无论是直接提供服务,还是想导流的,都着力打造自己的一款拳头小程序。

  我在这里说一个适合很多业务技术团队的通用套路,或者叫规划方法论。但是其中的具体内容要按照各自团队的情况具体做分析。

  在编程思想等内核方面,前端和后端会逐渐合流。2018年之后,谁要是再跟你说前端不需要后端(或 Java)那一套,请给他一个大大的白眼。前端社区如果想自立于技术社区之外,固守门户之见,那就只有死路一条。

  Service Worker 是一个特殊的 Web Worker,独立于页面主线程运行,它能够拦截和处理网络请求,并且配合 Cache Storage API,开发者可以自由的对页面发送的 HTTP 请求进行管理,这就是为什么 Service Worker 能让 Web 站点离线的原因。

  1. 首先,我觉得尊重团队的选择,很重要。我们最早有应用采用的是Angular,但团队最终也同时采用了Vue,而React也考虑过。而选择Vue的原因也很简单,就是上手快,相对简单,这点对进度很重要。一般来讲,团队的选择我是尽可能不会去抱悲观态度;

  工程化方向,年年都会提这个方向,不过今年可以考虑结合自动化尝试,无论是测试、开发都行,比如如何快速搭建一个能给业务方使用的后台管理系统出来(最好是别人搞,运营活动的什么不算)

  补充一个,webassembly是有戏的,对于高性能和代码复用真的好,非常有机会

  看了下上面同学的一些回答,我想站在公司管理层来看,或多或少都有些问题。太多回答都局限在技术里,脱离了实现价值。老大们哪里会在乎 React 比 jQuery 好在哪里,他们在乎的是能不能为业务带来增长,怎么去支撑公司的发展。

  从团队和个人两个方面来说说吧(团队方面不一定只是leader才能考虑,自己做团队贡献也是可以的)

  渐进式网络应用 ( Progressive Web Apps ),即我们所熟知的 PWA。 自 2015 年以来,PWA 相关的技术不断升级优化,在用户体验和用户留存两方面都提供了非常好的解决方案。PWA 可以将 Web 和 App 各自的优势融合在一起:渐进式、可响应、可离线、实现类似 App 的交互、即时更新、安全、可以被搜索引擎检索、可推送、可安装、可链接。 PWA 不是特指某一项技术,而是应用了多项技术的 Web App。其核心技术包括 App Manifest、Service Worker、Web Push、Credential Management API ,等等。其核心目标就是提升 Web App 的性能,改善 Web App 的用户体验。 下面我们详细地看一下这些核心技术,是否能够真正弥补 Web 劣势。

  其实规划只是我们工作最开始的一部分内容,规划完了并不代表任务就结束了,后续还要有持续的跟踪、把控和复盘,这部分以后有空再聊吧。

  前些年,前端是蛮荒时代,所以诞生了各种软件英雄,但现在,软件英雄的时代已经过去了,如果不想只做螺丝钉,就多学习工程化开发所需的知识和技能,学习如何跟别人高效、无意外的合作,甚至如何让大家都能高效、无意外的合作,这样才能成为团队中“特别的那个人”。

  Webassembly: 业务开发需求几乎为0,只有在极少数需要高性能的地方才能用到,可以预见的场景是挖矿、游戏、AR、VR,不是强需求,绝大多数团队根本用不到.

  从规划角度来说,一旦开始“规划”,就很容易想着面面俱到,也就不知不觉陷入空谈。

  正如你所看到的,我们为grid-template-columns写入了 3 个值,这样我们就会得到 3 列。 我们想要得到 2 行,因此我们为grid-template-rows指定了2个值。 这些值决定了我们希望我们的列有多宽( 100px ),以及我们希望行数是多高( 50px ),结果如下:

  基于以上四点我个人认为大前端的趋势会在国内继续蔓延下去,背后驱动的原因无外乎技术的成熟、公司业务的需求、成本上的考量、前端 leader 争夺话语权的考虑。

  这个词其实不是这一年出现的了,17年也出现过,但是搞头还在,主要针对现在前端场景多形态的一个落地,包括H5的pc端,移动端,微信小程序,支付宝小程序等不同场景下,前端er急需 write once,run anywhere 的解决方案。因此出来了像美团、京东等大厂的一些轮子,具体就不说了,关注的都知道。另外前端和客户端的一个未来发展,其实也可以归属于大前端架构的一个建设方向上,但是在一般而言前端和客户端是归属不同部门的,这个建设的难度很大,行业也一直在这个方向上探究,就像今天 Airbnb 突然放弃了RN,也不能不说是在这个方向上的一个思考;

  比如因为业务迭代不够即使,导致我们新功能上线很慢,对手在这方面超过我们,我们用户预估流失了 10%。这里发现的问题就是迭代速度慢。

  上面的过程都是对业务做分析,最关键的就是发现问题、定义问题、分析问题,把这几个事情做好,半只脚就踏进管理层了。当我们把问题搞清楚之后,解决办法就自然出来了。

  比如同样面对前端开发效率低和页面响应时间差两个现状的时候,我们怎么判断哪个重要,哪个不重要?

  这一步要做的就是发现我么已经做了什么,我们还少了什么,或者什么地方做的不够好,导致我们有问题。

  跟奇技淫巧和华丽的设计说再见,回归简约朴实的审美观,在工程领域,标准化的东西才是最美的。

  2、一定要去学一门后端语言,最好是java,去了解学习ng基本的配置,深入去学习HTTP协议!

  如果你不明白我们设置的只有 3 列,为什么有4条网格线呢?看看下面这个图像,我画了黑色的列网格线:

  上面是我这边设立的一个里程碑,对于一些基层的研发同学,时间区间可能要设立的更小一些,比如一个星期,半个月。

  这一步要做的就是罗列出当前小组的技术全景图,这种东西在后端很常见,但是前端很少见,也很少人会去这么做。

  比如你是个做前端基础建设的,可以分析我们支撑了多少部门,每个部门的使用率如何,业务方给我们反馈了哪些问题,问题的分类是如何的。

  这个词其实我觉得很大程度上是因为后端这两年springboot的一个流行,而引发出来的。后端的微服务思想,解决了原来后端架构的一个冗余、沉重的问题;而随着前端工程化的发展趋势,前端已经不仅仅是一套jQuery就打天下的时代(当然用jq也没有什么不好的),vue,react等框架带来的生态圈、技术栈,已经渗透了前端开发的架构,正如之前流行说的“2018前端是否有架构而言”的一个title,在工程化的暴风雨之后,如何让前端服务更合理,更微型轻量,变得尤为重要;

  iOS/Android 技术: 要明白 Rn 这种技术只提供了前端用 React 写原生的技术基础,不代表你就能写,掌握两个 native 平台的知识是开发跨平台应用的基本要求,我个人现在在同时写Android 和 IOS, 对于前端开发学这两门技术没太多压力,都是 GUI 开发,语言也都是 C 语言系的,要是换成 Haskell 怕是你一行都看不懂.

  其实学框架Vue Weex依然脱离不了前面高票答案里面的“快短糙” ,框架没多久就会变。而真正不会变的,恰恰是底层基础知识。例如通信相关的、例如渲染相关的、图形图像相关的。厉害一点的就把openCV OpenGL 搞定吃透的,基本上也就是大神级别了吧。到这个级别,无所谓用什么框架了,可能自己觉得顺手写出来的就是框架,反正是从MVC衍生出来的子孙框架。

  后台服务方面,serverless 应该是趋势——这个趋势并非小程序,众多的轻应用可以并不需要那么重的后台服务介入,一个全栈的前端工程师,Node + Taro/MPVue 就能满足大多数小程序的服务。这里的 Node 并非指必须要搭一个小程序后台服务,而是可以借助云厂商的无服务器函数,比如:

  各家浏览器厂商在 2017 年开始大力支持 PWA,连苹果都已经在几个月前悄悄的进行了 Service Worker 的开发了,iOS 也将支持 PWA。各大站点纷纷实践,用 PWA 已成趋势。

  3. 前端新东西很多,但也有比前些年相对多的技术相对稳定下来了,至少三大框架是如此。所以从个人角度来看,贪新鲜不如抓住最根本的,比如你在React上花个3年专心致志潜心研究,比学一大堆花里胡哨的东西管用得多。

  GraphQL可以试试,目前我团队在做一些尝试, 有效果了可以跟大家分享。

  3. 打造明星产品: 明星产品可以是业务产品,也可以是开源项目,目前我们的团队内部有一些不错的轮子,打磨好之后可以回馈社区.

  前端话语权越来越重: 在各种综合社区中经常看到前端跟各种后端干架的事情,当然前端自己圈子里打架也很严重,那么 iOS 跟后端干架吗? iOS 自己内斗吗?没有,人太少了打不起来,圈子太小大家都认识,互相吹捧一番根本打不起来,这几天在微博上的段子, 一个IOS大佬自嘲『圈子里太和谐都是互相吹捧,都不知道自己啥水平了』,都说前端是娱乐圈,实际上从另一方面讲是人越来越多,各种奇葩事也断不了,以上是从社区的角度来讲的,从公司角度来讲,通常情况下,一个前端 Leader 手底下的人要比客户端多很多,涉及的业务也要多得多,比如 node 的中间层业务、PC 端业务(WEB 和客户端)、H5业务甚至一些可视化的业务,其中最关键的其实是 Node 层的业务,这是前端团队区别于客户端的巨大优势,说白了大家都是 GUI 开发,除了后端用 Go或者Java之外,中间层的 Node 是真正直接给 GUI 层提供 API 的关键,而这把钥匙在前端团队手里。

  TypeScript,现在立刻马上学 —— 学到精通。这是一个注定要成为明星的技术,永远不要小看 Anders。

  接下来是如何在 grid(网格) 上放置 items(子元素) 。特别注意,这里才是体现 Grid 布局超能力的地方,因为它使得创建布局变得非常简单。 我们使用与之前相同的 HTML 标记,为了帮助我们更好的理解,我们在每个 items(子元素) 加上了单独的 class :

  虽然 webpack 带来了许多可配置性,同事也造就了它的复杂性。 而 Parcel 带来简单性。 官方号称 Parcel 为 “零配置” ,开箱即用。正如上面所说的 – Parcel 内置了一个开箱即用的开发服务器。 开发服务器将在你更改文件时自动重新构建你的应用程序,并支持模块热替换以实现快速开发。 Parcel 有什么好处? 1.快速打包 – Parcel 比 Webpack,Rollup 和 Browserify 更快。 2.Parcel 支持 JS、CSS、HTML、资源文件等等 – 无需插件 – 更加便于用户使用。 3.零配置。开箱即用的代码拆分,模块热替换,CSS 预处理器,开发服务器,缓存等等; 4.更加友好的错误日志。 我们应该什么时候使用 Parcel , Webpack 或 Rollup 呢? 这完全取决于你,但我个人会在以下情况下使用每个打包器: Parcel:中小型项目(代码行小于 15k) Webpack:大型以及企业级项目。 Rollup:用于 NPM 包。 让我们给 Parcel 一个机会 。

  我个人认为就现在国内的趋势而言,前端把 iOS 和 Android 统一了是迟早的事情,原因如下(仅国内):

  比如你是个做电商的团队,可以从几个指标来分析我们的业务现状,比如PV、下单量、留存率、用户增长等等等。

(编辑:admin)
http://argentinet.com/qianduan/80/