前端工作量大還是后臺(tái)工作量大？作為一個(gè)在后端工作了四年，在前端工作了一年半的工程師，讓我客觀一點(diǎn)。首先，就技術(shù)棧的復(fù)雜性而言，前端和后端并不淺。那些只知道后端的人認(rèn)為前端是兼容的，那些只知道前端并認(rèn)為

前端工作量大還是后臺(tái)工作量大？

作為一個(gè)在后端工作了四年，在前端工作了一年半的工程師，讓我客觀一點(diǎn)。首先，就技術(shù)棧的復(fù)雜性而言，前端和后端并不淺。那些只知道后端的人認(rèn)為前端是兼容的，那些只知道前端并認(rèn)為后端是積垢的人都是高估者和低成就者。一個(gè)人的精力是有限的，每一條技術(shù)路線都可以深入很多內(nèi)容。事實(shí)上，一個(gè)程序員大部分時(shí)間都在解決如何實(shí)現(xiàn)某項(xiàng)業(yè)務(wù)，如何優(yōu)化和改造一個(gè)老項(xiàng)目的問(wèn)題，尤其是在一個(gè)大工廠里。不要高估螺絲釘?shù)淖饔谩?/p>

所以當(dāng)我們討論誰(shuí)有更多的工作，根據(jù)概率，基本上沒(méi)有區(qū)別。但是你要討論的問(wèn)題只有少數(shù)人和少數(shù)情況需要面對(duì)，比如前端的跨端開(kāi)發(fā)方案，如何平滑各端之間的差異，如何克服各端動(dòng)畫(huà)性能的瓶頸，以及高并發(fā)性、高可用性、數(shù)據(jù)庫(kù)子系統(tǒng)表方案、緩存方案、安全策略、通信方案等。那些面臨這些問(wèn)題的人已經(jīng)被少數(shù)人解決了。市場(chǎng)上的大多數(shù)人，不是螺絲釘，就是信條，真的，誰(shuí)也不看不起誰(shuí)，我們都是農(nóng)民工，工作內(nèi)容差別不大

為什么國(guó)內(nèi)的uniapp一直沒(méi)人討論呢？

可以制作任何玩具應(yīng)用程序或演示，但不能認(rèn)真開(kāi)發(fā)。許多問(wèn)題還沒(méi)有解決。和玩一樣。在本地制作包和更改庫(kù)很容易。IOS有很多問(wèn)題，連接外設(shè)也有很多問(wèn)題。政府不能提供任何好的建議。另外，包裝改變后引用資源的方式今天的圖片版本是這樣引用的。明天，升級(jí)開(kāi)發(fā)工具然后打包圖片的路徑將是錯(cuò)誤的。你為什么說(shuō)一切都不穩(wěn)定？以上是我個(gè)人的經(jīng)歷。公司花了20多個(gè)星期的時(shí)間用一個(gè)新的框架進(jìn)行重新開(kāi)發(fā)

你好，開(kāi)發(fā)像美團(tuán)這樣的應(yīng)用程序不能用一種語(yǔ)言實(shí)現(xiàn)。一個(gè)應(yīng)用程序有兩個(gè)操作系統(tǒng)，Android和apple。有很多主流的開(kāi)發(fā)語(yǔ)言和技術(shù)可以應(yīng)用在Android IOS上，比如Java和C在后臺(tái)，前端包括kotlin、HTML、CSS、jQuery、AJAX、bootstrap角度.js、反應(yīng)虛擬用戶.js、 節(jié)點(diǎn).js、swift、Object-C等語(yǔ)言和框架。

應(yīng)用的開(kāi)發(fā)需要前端技術(shù)和后端技術(shù)的配合。這樣的應(yīng)用在功能和性能上都給用戶帶來(lái)了很好的體驗(yàn)。畢竟單一開(kāi)發(fā)語(yǔ)言的技術(shù)支持是有限的，所以即使可以開(kāi)發(fā)，應(yīng)用的用戶體驗(yàn)也不理想。

通用應(yīng)用有以下開(kāi)發(fā)組合模式：1。原生Android IOS開(kāi)發(fā)，前端：Java、kotlin、swift、Object-C，后端：Java、PHP、C等后端技術(shù)，這種模式開(kāi)發(fā)周期長(zhǎng)，成本高，性能好?；旌蠎?yīng)用開(kāi)發(fā)，即混合應(yīng)用，前端主要是網(wǎng)頁(yè)技術(shù)，穿插著原生開(kāi)發(fā)功能，既有原生應(yīng)用又有web應(yīng)用，app的優(yōu)勢(shì)，如淘寶、微信等應(yīng)用都是基于這一技術(shù)的。webapp是前端純Web技術(shù)，后端是主流開(kāi)發(fā)語(yǔ)言，具有開(kāi)發(fā)速度快、成本低、界面體驗(yàn)弱等優(yōu)點(diǎn)。

可以看出，應(yīng)用程序的開(kāi)發(fā)主要是用多種語(yǔ)言完成的。謝謝你的閱讀。