當前位置:首頁 » 網頁前端 » 為什麼css前端那麼難
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

為什麼css前端那麼難

發布時間: 2022-07-13 09:04:30

前端是有多難看完你就知道了

最近感覺追不動前端的發展了,寫篇文章感嘆一下。
HTML
我知道有一些學校會教一些簡單的網頁製作,就是用 Dreamweaver 點一點的那種。大多也會留作業,最後交作業的時候看起來也像模像樣。
只要不看代碼。
看了代碼感覺寧願選擇死亡。
table 布局,無意義的 dom 節點。大小寫混用,縮進混亂。
作為一個前端工程師,至少要寫明白自己寫的聲明是什麼意思對吧?
然後還得減少不必要的 dom 節點,畢竟很多文章說節點多會影響渲染速度(ps: 我是不在乎的,我覺得有點兒矯枉過正的味道了)
然後比較重要的一點兒是對於語義化標簽的見解。比如什麼時候該用 ul, 什麼時候該用 section, aside
至於 head 裡面的那些無聊的聲明只要會復制粘貼就好了,我覺得沒什麼意思
自信做到這些的應該算差不多了
文章說的是前端有多難,很多人都覺得這些標簽簡單。然而想像一下,要寫多少的標簽才能理解語義化的意義?要寫多少頁面才能真正的明白這個節點應該寫什麼標簽?如何組合才算合理?
CSS
然後是關於 CSS,我覺得這方面是很復雜的。並不像很多人覺得只是一些單詞的組合。
一開始我會改 background-color 覺得開心得不行,以為掌握了
後來無限突破視野。
在第一次寫超過50個class之後就感覺想死,重復性勞動,樣式修改調試,寫法丑。。。
接觸到 Sass 之後像是發現了新大陸,有一段時間甚至不會寫原生 css 語法了。
然後折騰: Sass -> Stylus
到這里結束了么? naive
後面還有postcss, cssnext 這些東西。
在 react 生態中還有 css-moles, css-in-js 這些鬼東西。
雖然語法都不是很難。但是這么長時間的折騰下來,雖說提升是有的,但並沒有感覺到生產力有多少巨大的提升。
css 到這里還沒完。
還有BEM的命名方式要去理解。
到這里依舊沒有完。
css3 的新特性,還有各種 hack。比如如何實現footer始終在底部,內容始終撐滿全局?如何實現條紋?
到這里結束了么?
依舊沒完。
css stage 4 等著去學習。
還有精力?
可以試著多做些兼容性相關的東西。會崩潰,相信我
到這里?
在我的視野中差不多算結束了,然而有誰能確定明天有沒有一個什麼new-css之類的東西解決什麼問題。
JS
來了來了,前端的一個核心。
說JS輕松么?咱們來扯扯。
首先是各種 dom 的增刪改,然後是ajax相關。學會了差不多能做簡單的頁面了。
然後對非同步的理解。只有理解了非同步才能正常地寫js。
然後是對js語言特性的理解。比如ES5如何實現繼承什麼的,閉包。
總之這些就是面試題總是會問的東西。
之後還應該理解設計模式對吧?
到這里是正常的語言應該學習的內容了。然而js到這里只是起步。
之後一個前端工程師還得會 ES2015/2016 之類的吧。現在不寫個async誰好意思說自己是寫前端的?
之後應該是配合工具了,後文說。
繼續順著語言往下說。會了 ECMAScript 就能做個合格的前端了么?
還早呢。
之前火的 coffee script 現在不行了,然而 TypeScript 火了啊。不學一下怎麼好意思追前端?
ts 對於之前寫 Java, C# 的非常友好,基本語法沒什麼變化。然而可苦了那些不寫這些語言的同學。語法改變倒是其次,思維方式的轉變才是難以接受的。
現在還有 Elm 了。。。
我覺得我老了,追不上了

㈡ 為什麼他們說html+css.很簡單而我學得那麼困難

css語法簡單,應用復雜。

很多人說css簡單,只是因為覺得css的規則簡單,很容易理解。但是真正實現起來的時候,才會發現有各種問題和疑難雜症。兼容性等等。

css的難點有

  • 定位

  • 布局

  • 動畫

  • 代碼組織結構

  • 優先順序

等等,都需要大量的實踐經驗之後才能掌握的。所以真正學好css並不是一個想很多人說的那麼簡單的事情,即便我在前端工作快6年了,最容易遇到問題的也還是css,最難寫的特別漂亮優雅的也是css。

㈢ CSS難不難學

CSS一點都不難學,前端最難的地方還是Javascript這門語言。不僅要邏輯思維能力強,還要不停的去操作,去學習才行。

㈣ 會CSS轉到前端開發難不難

前端就是Html+Css+Javascript,其中最難的是Javascript,最簡單的是Html,現在基於JS出現了Jquery,基於Jquery又出現了Vue,AngularJs等框架,想要轉到前端的話,這些框架都需要熟悉,如果不會JS的話,那可能還需要用一段時間來學習JS,以及JQ、Vue、AngularJS,有一定的難度,而且雖然現在很多企業都缺前端,但是他們對前端的要求還是比較高的,一般是需要有經驗的前端,具體是否要轉前端開發,還是要看樓主自己了。

㈤ 前端開發的難點到底在什麼地方

一般意義上的前端項目:

-從0到1,治理曬哦為健全點的都能搗鼓出來;

-從1到60,後後端或者設計崗位勉強能兼任;

-從60到80,需要比較專業的前端;

-從80到100,這么好的前端可遇不可求。

從0到1就是從無到有的過程,很多人用WordPress,建站之星就差不多就能搞個demo了,可以拿去騙投資人的錢。

從1到60,就是勉強可用,基本上讓後端工程師或者UI設計師找一套bootstrap的模板東拼西湊的也能勉強應付到第一版本上線。

從60到80,就是真正要做一款能完備、性能優良、架構合理的中小規模產品,沒有專業的設計、前端、後端、產品、運營是走不到這步的,差不多到A輪了。

從80到100,那就是追求各方面的極致,與競爭對手一較高下,各個方面沒有頂尖的人才都會影響整體的戰鬥力,木桶效應。

解釋一下:

1. 核心競爭力的主體是工程經驗。
其實這個結論可以推廣到其他研發崗位,就是每個研發崗位的知識體系都是由基礎學科知識+領域工程經驗構成,彼此不可替代的就是工程經驗部分。一個後端工程師一時間不能替代同等級前端工程師到不是基礎或者智商的問題,主要是工程經驗不足,你讓一個前端一個後端分別實現對方領域中一個有明確輸入輸出的功能函數,二者通過簡單學習新語言新語法,加上開發手冊查詢,一般都能比較正常的實現業務邏輯,但你讓他們hold住對方領域的完整項目就很困難了,技術選型,系統設計,模塊拆分,平台特性,宿主環境,性能優化,構建部署,系統測試等等都是領域工程經驗問題。

2. 工程經驗的等級是能cover項目從0發展到80+。
這個很好解釋,因為從0-60的非專業前端也能做到,60+的才是專業前端。

所以不用擔心核心競爭力問題,60+的前端現在都很搶手啊。工程經驗只有60-的話確實壓力比較大。

㈥ 前端開發很難嗎

相較於其它編程類技術,前端開發是最易學的一門技術。可以這么理解,Web前端開發技術是一個先易後難的過程,它主要包括三個大的技術架構是:HTML、CSS、JavaScript。

HTML是一種超文本標記語言,就是結構標簽,並不會涉及到復雜高深的技術邏輯,更多時候是需要牢記、背下來一些標簽的作用。所以這個學習階段主要考驗的是記憶力,如果記憶力不好也沒關系,可以多記筆記,需要用到什麼功能的時候看筆記就可以,時間長了代碼練習多了自然就記住了。

CSS的學習方式和HTML大同小異,它的作用是樣式配置,更多時候也是一個死記硬背的過程,不涉及太復雜的邏輯。

比較有難度的是學習JavaScript的過程,這個階段需要接觸到很多復雜的邏輯。HTML和CSS需要互相結合學習,只學習這兩個只能展現一個靜態界面,如果想要增加動態的效果就必須要學習JavaScript。靜態頁面是比較容易就可以實現的,功能全面的動態頁面需要很多復雜邏輯技術的支撐,JavaScrip就是實現這些功能的主要技術。

㈦ 前端開發的難點到底在什麼地方

  • 不同級別的前端面臨的難點各不相同,不可一概而論;

  • 業務開發的前端難點在於對業務的理解和把控能力;

  • 平台開發的前端難點在於產品化的把控和推進能力。

  • 觀點1:不同級別的前端面臨的難點各不相同,不可一概而論。

    其他回答有說 CSS 難,有說 CSS 不難的,每個人水平不同,這樣爭論毫無意義。我剛學前端時覺得 JS/CSS/瀏覽器兼容問題都很難,現在覺得也就那樣,因為前端路子廣,辦法總比問題多。後來覺得要評估好需求,把控好項目質量比較難,很多時候我們是在幹事,在解決問題,不是只埋頭寫代碼,時間一長你會發現前端工作中,技術問題往往比較好解決,反而資源+協作問題比較麻煩。現在對我來說比較難的是快速產品化的能力,如何從無到有去做出一些有價值的東西。

    舉一個簡單粗暴的例子吧:阿里前端很多,P5/P6 一大把,但是 P8/P9 的非常少,為什麼?進階的難點在哪裡?

    前端開發的難點跟前端進階的難點是非常相似的。阿里對每個前端層級都有一個標准,這也從側面回答了這個問題,比如對 P5 來說,難點可能是寫好業務代碼,保證其靈活性和可維護性,能解決各種適配問題;對 P6 來說則需要獨擋一面,能獨立 owner 需求,而 P7 則需要在某方面技術有深入理解,等等。

    能提出這個問題首先得恭喜題主,說明題主在當前階段遇到瓶頸了,需要向下一個 level 出擊了。

    觀點2:業務開發的前端難點在於對業務的理解和把控能力。

    業務邏輯開發本身並不是難點,誰都可以寫。但是對於你自己負責的這塊業務,後續業務的發展方向和潛力,你有去了解過嗎?當業務方提需求過來時你是只負責執行還是和業務方一起探討更合理的方案?你有沒有給自己負責的產品提過一些建議?做過一些改善措施?如果前端只是作為一個執行者,作為一種被調度的資源,那麼即使最終項目取得了好的成績,跟你有多大關系?你自己會有多大的成就感?

    另外一個很重要的點:就是對業務的把控能力。業務方總是會催著上線,開發時間不斷被壓縮該怎麼辦?進度不如預期怎麼辦?開發遇到瓶頸怎麼辦?發布新功能翻車了怎麼辦?

    我見過有默默加班保證進度的,也有跟需求方重新談延期的,有發布出問題手足無措的,也有自己默默修復的,有遇到瓶頸一籌莫展的,也有及時跟老闆溝通,跟業務方撕逼的… 如何優雅的處理這些問題,有時候比寫代碼更難。為什麼有的人業務代碼邏輯混亂,寫的一團糟?我不相信是智力問題,反倒更相信是對項目本身沒有把控好,本來排了5天工作量的需求被業務方壓到了3天,你還能保證寫出健壯而不失風度的代碼?

    觀點3:平台開發的前端難點在於產品化的把控和推進能力。

    做業務時有人給你提需求,幫你出交互視覺稿,你只要負責寫頁面就行了。但是在支付寶前端,很多內部平台和技術產品都是技術自己主導,你需要自己發現問題,出方案,設計資料庫,自己出頁面,這是一個從無到有的創造的過程。並且要保證你做的東西是真正解決問題的,而不是做一些自己覺得很牛逼實際上並沒有解決用戶痛點的東西,用我老闆的話說就是對產品的把控能力,不要跑偏了。前端是最容易做出產品化東西的工程師了,因為後端不會做 UI,UI 不會寫代碼,唯前端兼顧,這是最大優勢。

    再一個就是對產品的推進能力了,你做的東西可能需要各種資源?如何爭取?可能牽扯到多方利益?如何權衡?東西做出來了如何推廣?如何在用戶的一片罵聲中奮勇前進?

    印象中很多平台型產品,剛開始投入使用時都是一片罵聲,各種問題,說實話負責這些產品的程序員壓力是相當大的,天天被罵還得徹夜幫別人解決問題,還得不斷優化系統,你說難不難?

    以上三點就是本文所展現的理念,希望能對大家有幫助。