如果說當一個軟體工程師也有分階段（見山是山、見山不是山、見山又是山），那我想現在的我一定是在‘見山不是山‘的階段，寫下現在的想法，希望自己幾年後再來看，可以邁入見山又是山的階段。
網站的技術發展從Web2.0的年代到後來智慧型手機普及後RWD網站變成標配的現在，發展上不管是前端或是後端都經歷了很大的轉變，對我來說前後端是緊密不可分的；雖然常有人說沒有真正的full stack，不過我認為一個full stack並不是要同時專精於前後端，而是能夠知道前後端所需要處理的事項，如此一來不管工作是做前端還是後端，都可以知道另一邊的工作是什麼、雙方應該怎麼配合寫起來才順暢。
以往桌機 1024 x 768 的年代，多數的HTML都是使用<table>來完成，每個網站看起來標標準準整整齊齊，頁首、內容、頁尾排列方式大都相同，當時的設計，簡單的css樣式就能滿足，網站頁數通常也不多，常看到將css寫在頁面上的(in page style)，並不是奇怪或者是很難維護的事。
網站應用程式開始發展後，開始出現了百萬人數訪問的網站（電子商務、售票網、大型論壇），這時候後端工程師常需要同時處理資料庫(現常稱為DB ENGINEER)以及伺服器(現常稱為DevOps)，後端工程師的薪水往往大幅超越前端工程師。如何讓網站推不倒是當時主要的客題。
伺服器穩定後開始發展起了後端程式碼維護的相關模式，各種MVC design pattern陸續問世，Python Django, Ruby on Rails, PHP Symphony, Yii, CodeIgniter等framework 開始讓工程師互相合作整合程式碼，前端工程師專注在View and Controller(多數狀況只需要知道Controller吐出什麼資料)，後端工程師專注在Model and Controller。
第一支智慧型手機問世後，網站開始要能在手機上瀏覽，開始了RWD( responsive web design )前端網頁開發的年代，大家開始用media query讓網頁可以自適應各種瀏覽器尺寸，從手機、平板、筆電、桌機都要能瀏覽，<table>這種本身非responsive的元件，反而變成能少用就少用。這時候出現了很多前端的切版框架：bootstrap, foundation, pure等css framework 幫助前端工程師能夠快速的切出一個RWD網站版型。
接下來進入了前端開發者的戰國時代，因應著JavaScript的廣泛使用，各種前端的框架開始出現，從最早的ember, backbone, angular, react一直到最近的vue ，每個框架主要目的都有些不同，但通常出發點都是能夠透過SPA( single page application )去減少伺服器的負載同時也減少前端的負載：簡單說，使用者換頁時不再需要重新發出請求到伺服器等待回傳一個新的頁面，而只要請求需要更新的資料然後更新頁面，減少了伺服器吐出的資料大小，也加速了使用者看到網頁變化的時間。
不過（轉折點來了）事情沒辦法就是這麼單純，SPA的缺點就是網頁只有一個頁面網址，即便透過一些前端router來操作網址，許多重要的meta資訊，網路爬蟲爬不到，甚至頁數不夠沒有結構化的頁面內容，如此一來網站的SEO排名就不容易上升，所以開發者們又開始專注以前沒有前端框架時不會處理到的問題，用SPA並且使用SSR( server side rendering )讓網站的SEO可以比較好。
打了這麼多，想說的是現在許多公司或者是開發者開始一窩蜂熱使用框架去開發網站往往是讓我最難理解的事情，事實上，多數的網站都是非高流量非高效能的一般網站應用程式，若是很單純的使用後端MVC不僅可以搞定基本前後端架構同時SEO也可以輕鬆達成，未必需要變成是一定要後端API搭配前端框架。
每種框架都有他的優缺點，如何判斷並且了解網站需要使用什麼樣的架構是每個資深工程師很重要的課題，技術的發展是用來解決問題，但近年來的開發者的選擇真的常常讓我不解；(舉例來說，一個只有一頁有預約功能網站也要做前後端分離然後導入React Js。) 如此一來，開發上往往為了達成某件事而要多做很多事，除了檯面上那幾個大型流量或者是特殊功能需要的網站之外，其他網站的架構真的需要這樣嗎？
回頭呼應首段，上面描述的多數是我個人心得，也簡單解釋了為什麼我認為我處於”見山不是山”的階段，這未必是個好比喻，但總覺得開發者在技術的發展以及選擇上只是在繞圈圈(SSR -> SPA -> SSR)，希望這篇文章提醒自己在幫別人分析網站時可以跳脫出最火紅的框架去思考什麼是最好的建議，同時也希望幾年後回顧，我可以有重新的”見山又是山”的新領悟。
