整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
TML 5雖然只是一個技術標準，但是眼下更多承載著顛覆蘋果與谷歌移動生態的理想。我并不想單純從技術角度談論HTML5的現實處境，因為技術從來不會成為發展的絕對瓶頸，尤其是HTML 5本身就不存在任何重大的技術難題。反而“商業”成了HTML 5發展無法逾越的鴻溝。只可惜“商業”從來都摻雜大量的投機成分，當然也有商業政治的成分。
HTML5所謂的“標準定稿”在我看來只是一場公眾秀。HTML 5標準自始至終就不是W3C組織一家的自留地，更不是唯一的代言人。原本W3C組織對外宣傳“要到2022年才會完成HTML 5正式標準的頒布”，現在為何又如此匆忙的定稿？這種定稿真的會對移動開發產生多大影響？
最糾結的10%
真正一直關心HTML 5的人會記得2012年7月的一個重大新聞，HTML5的兩個標準組織W3C和WHATWG因為“理念不合”決定分道揚鑣，這被看成一場IT界的商業政治事件。二者的根本理念差異是WHATWG認為HTML 5應該成為一個動態的標準既Living Standard，而W3C則認為應該形成一個固定的標準。導致這場事件升級的真正原因并不是“理念”這么簡單，而是二者各自代表的利益集團背后的推手。WHATWG向W3C叫板的底氣，正是來自Mozilla、蘋果和Opera的支持。W3C則選擇了微軟。
HTML5標準本身涉及的技術并無任何障礙，但是之前遲遲無法定案的原因則是錯綜復雜，緩慢的進度除了再一次證明這些組織是超級低效機構之外，所謂的利益和政治博弈才是直接導致了進度緩慢的真正原因。實際上截止2013年90%以上的HTML 5的標準早已完成，剩下的部分恰恰是各大利益集團博弈的重點，此次W3C代為發聲，明顯生米煮成熟飯的意味，這真的會奏效么？答案是完全否定的！因為各大金主不會因為一場PR活動就放棄自己的利益。
那么對開發者和技術用戶而言，W3C所謂的標準定案到底意味著什么？是否可以從中獲益？到底該如何看待這一“進步”？
這一切還要從W3C與WHATWG的分歧開始，動態標準還是固定的標準更適合開發者？我想，答案或許是WHATWG的Living Standard！因為沒有動態的標準，就不會有HTML 5的未來。未來HTML5想得到真正的發展，核心問題并不是標準哪天定稿亦或是瀏覽器性能不足，關鍵在于兩點，一是持續改進，二是生態。
龜速迭代
如果沒有一個持續改進的標準和為此而不斷努力的組織，HTML 5就只能把顛覆App生態當成一句口號，永遠充當配角。因為生態革新速度要遠大于開發者的行動速度。
IT world已經完全不是10年前的樣子，Cloud/Client“云與端”快速蠶食著傳統B/S架構（瀏覽器到服務器）的空間。端不特指“手機端”而是更廣泛的包含“pad端”“PC端”甚至“手表端”“汽車端”“家電端”等等。而相比PC時代，更多端的出現，代表著更多的硬件組合以及更多業務場景和功能。我們一直詬病W3C等標準組織行動緩慢，這次標準的公布很明顯沒有解決任何“云與端”復雜性的解決方案。我們設想一下：
場景A：以iphone的touchID為代筆的生物識別功能在各種端上興起，繼而產生了大量新的API，甚至可能今后帶有硬解的虹膜識別、聲紋識別等終端能力，在一個固定的HTML5標準下如何解決？HTML5附帶的device API甚至只涵蓋了feature phone時代的基礎通訊錄、攝像頭等功能，今天出現的touchID均無法有效調動，更何況2、3年后我們無法認知的新功能的標準配套實現。這種情況下不發展的HTML 5標準代表著“弱功能”
場景B：智能硬件的發展對藍牙和wifi使用以及驅動的需求迅猛增長，而HTML 5配套的對藍牙3.0驅動的支持標準何在？可以遵照標準的HTML 5亦或是配套的標準以及協議在瀏覽器內連接大部分的智能硬件么？答案當然也是全然否定的。這種未來最常見的常見之一都無法實現，那些大談HTML 5將會取代APP的人恐怕又會說“這些不是HTML 5擅長的，這種舉例毫無疑義”。那請問HTML 5擅長的只是排版布局和閱讀類亦或者一些低價游戲的APP么？更不要說對于NFC等很快可能成為終端標配的系統新能力，所以定稿后不發展的HTML 5標準代表著“弱擴展”
其實，這一切基于HTML 5的論點并非沒有明確的解決方案，簡單來說所謂的HTML 5定稿只是鬧劇和PR，如果真正期盼HTML 5挑戰App生態，一定要出現一個不停發展的動態標準，才能夠具備上場參賽的基礎。只是這倚重的是標準背后的“推手”和“金主”，那些想打造自己生態王國的大玩家。作為WHATWG的重要支柱，蘋果公司一直在低調中快速發展著自身的Web App技術，到今天為止，在iOS中已經有比Android和其他操作系統更成熟和完美的圍繞HTML 5和Web App的支持，只是遺憾的是蘋果公司只是把HTML 5當成技術，而沒有為打造HTML 5的生態做出任何其他的努力。
推不動的生態
2013年是HTML 5最低調的一年，因為在此前一年，眾多打擊接踵而至，除了用戶對HTML 5普遍負面的反饋之外，最嚴重的一次事件就是Facebook的徹底反水！
扎克伯格：我們過去最大的錯誤就是在HTML 5上面賭太大！
曾幾何時，面對HTML5扎克伯格野心勃勃的推動著“復制Facebook在PC端生態和霸權計劃”。眾所周知，蘋果的生態系統是相當封閉的，Android雖然開放但是也全面復制著蘋果的玩法iOS－>Developer－>APP－>Appstore－>User。所以Facebook全面推進HTML 5，妄圖跳開移動操作系統的掌控，擁抱HTML5和www的開放流量體系。
但是即便是Facebook如此重量級的玩家，最后也認栽了。無獨有偶，Linkedin作為又一風向標，在2013年也同樣放棄了HTML 5重新擁抱APP。到今天，難道短短的一年多，世界就發生了徹底的改變，HTML 5又重新具備了王者的氣質？當然是不可能的，世界上各個IT王國都沒有改變，改變的只是時間。
根據Flurry的報告，相比去年，2014年用戶在移動端的使用APP的份額進一步上升突破80%，而手機網站的使用情況進一步被擠壓。這說明用戶市場沒有將APP升級和下載當成多大的困難（至少沒你想像的那么困難），并且隨著App store更加人性和智能化的幫助用戶在wifi環境下自動升級等機制的普及，APP在使用上對用戶來說門檻越來越低，反而基于HTML5的Web App的使用和獲取倒是成了用戶的障礙。手機瀏覽器的用戶留存和使用情況越來越不樂觀，這個最重要的HTML 5的載體正在失去活力，反而大家寄望于超級APP，微信在中國眼下成了一根救命稻草。
當然想基于超級APP的形式打造自身閉環生態的廠商不止Facebook一家，反觀國內試水的大公司也很多，但均以鳴金收兵結尾。從UC的web app商店到百度的輕應用，構建基于移動web流量的生態系統無一成功。目前造成這種局面原因眾多，例如瀏覽器性能不足、HTML 5標準未定稿、無有效的web app發行渠道等等，但是正如我3年前說的，最核心的問題是移動開放流量體系和原生生態系統的對抗。
目前用戶從App store去搜索和下載app，在桌面存留app入口點擊使用，這已經成了iOS與Android生態系統下的固定模式。反而讓用戶進入超級APP，再通過搜索或連接的方式進入一個第三方web app，無論是從操作流程還是用戶最終體驗都無法和操作系統層級的體驗抗衡。而HTML 5標準定稿沒有為這種生態的困難帶來任何一點的改變，所以說HTML 5在W3C操縱下的所謂標準定稿，只是一場PR的鬧劇，雖然攪動了市場，但是也刺激了一批從業者充當炮灰。
期待新玩家
打造移動開放平臺和生態系統，微信是佼佼者，并且成功將部分App的流量轉化成了Web app的流量。微信也一路創新了導流手段，沒有選擇用戶網址輸入、也沒有選擇用戶搜索進入web app，而是把賬號變成網址并且直接收藏的方式，形成了一個特殊的“web app瀏覽器”。在打通了流量后又恰當的加入了支付手段，不但盤活了流量也讓流量變得更加有價值。
這給HTML 5開發者帶來了希望，不過很快又很失望，因為開發者發現微信對流量的管控超乎預期。這讓我想到了SNS時代開放平臺玩死眾多social game廠商的過去。中國有大的互聯網開放平臺，曾經的騰訊、人人甚至淘寶。但是總結規則無一不是“貔貅原則”流量只進不出，所謂的盤活流量只是為自身生態服務，雖然這樣無可厚非，只是對于開發者來說把自己的夢想嫁接在“中國版的開放平臺上”無異于“與虎謀皮”。因此HTML 5生態的建立或許可以借助開放平臺，但是真正可以對抗原生生態的HTML 5需要的是類似于WebOS這種更徹底的變革。
開發者對于HTML5的定稿，心態大可保持平和，短期內不會帶來任何的實質性改變。瀏覽器特別是操作系統廠商也不會因為W3C標準的定稿而放棄一直維護的自身利益，該支持的早已經支持，不該支持的也不會遵照標準去支持。只是HTML 5作為進步的一代標準，拋開利益和政治的博弈，還是會給開發者帶來更多的價值。只要不盲從，以學習的心態積極對待，仍會從中獲益。
HTML 5和配套的web開發技術具有跨平臺、低門檻的特性，目前大量的APP中廣泛使用了HTML5配合native development原生開發，極大的降低了APP整體的開發成本，更有一些移動應用引擎使用Javascript和HTML 5開發跨平臺native app，在不觸碰iOS與Android生態利益的前提下，發揮實用的價值。因此只要回歸到技術本身，把HTML 5技術應用到可以使用的場景中充分發揮價值，就可以逐步迎接更光明的未來。
2年前，移動開發領域掀起過一次行業大辯論“web app和native app誰死誰活”的問題。今天這個問題依然是一個有價值的問題。所以下一篇是，HTML 5盛宴（二）：再論Web app和Native app的未來。
本文作者劉鑫，移動云服務APICloud創始人兼CEO，從SP夢網時代就開始持續關注移動Web開發，個人郵箱hi.seanliu@yahoo.com
除非注明，本站文章均為原創或編譯，轉載請注明： 文章來自 36氪
36氪官方iOS應用正式上線，支持『一鍵下載36氪報道的移動App』和『離線閱讀』立即下載！
家好，我是開源探索者，持續分享開源項目，關注技術的最新動態，分享自己的經驗和見解。
大家好，我是開源探索者。
今天給大家介紹一個非常牛的開源項目：Screenshot-to-code。
Screenshot-to-code 是一個可以將屏幕截圖轉化為 HTML/JS/Tailwind CSS 代碼的工具。它利用 GPT-4 Vision 生成代碼，結合 DALL-E 3 生成相似的圖片。
能夠將屏幕截圖瞬間轉變為可運行的代碼。這意味著，你只需要截取一個網頁或應用程序的截圖，Screenshot-to-code 就可以自動生成對應的 HTML、CSS、JavaScript 代碼。
這項功能對于初學者來說非常友好，可以幫助快速學習前端開發。對于經驗豐富的開發人員來說，也可以節省大量的時間和精力。
項目利用最新的 GPT-4 Vision 技術，可以生成高度智能化的代碼，能夠幫助我們更好地理解屏幕截圖中的元素，并生成更加貼近設計意圖的代碼。
可以結合 DALL-E 3 技術生成相似的圖片，我們可以使用 Screenshot-to-code 生成一個網頁或應用程序的截圖，然后使用 DALL-E 3 生成一個相似的圖片。
這項功能可以讓我們的頁面呈現更加豐富多彩、獨具特色。
一個例子
Screenshot-to-code 的使用很簡單，官方給了很詳細的說明。
使用前提是有一個能夠訪問 GPT-4 Vision API 的 OpenAI API 密鑰。
接著按照下面的步驟：
1、下載 Screenshot-to-code 的源代碼。
2、在 backend/.env 文件中添加你的 OpenAI API 密鑰。
3、使用 poetry install 安裝依賴項。
4、使用 poetry run uvicorn main:app --reload --port 700運行后端。（如果您希望在不同端口上運行后端，可以修改文件 VITE_WS_BACKEND_URLfrontend/.env.local）
5、使用 yarn 安裝前端依賴項。
6、使用 yarn dev 運行前端。
7、打開瀏覽器，訪問 http://localhost:5173 即可使用。
如果你安裝了Docker，也可以用下面的命令快速開始：
echo "OPENAI_API_KEY=sk-your-key" > .env
docker-compose up -d --build
當然，如果你也不想這么麻煩，官方提供了一個在線的版本供體驗使用
https://screenshottocode.com
目前 Screenshot-to-code 項目依然還在開發更新中，已經取得了令人印象深刻的進展。未來，Screenshot-to-code 會在支持更多的語言和框架、提高生成代碼的準確性和效率、增加更多功能，例如代碼片段共享和代碼編輯器集成等方面進行提示。
開源君有一種感覺，Screenshot-to-code 有可能會成為未來前端開發的必備工具。
關于項目的更多細節，感興趣的同學可以自行去項目地址查看。
項目地址：
https://github.com/abi/screenshot-to-code
在數字時代的浪潮中，有一群人他們不畏艱難，勇攀技術高峰，他們就是開源探索者。他們不僅僅是技術的實踐者，更是開源文化的傳播者和推動者。
在開源的世界里，沒有絕對的權威，只有共同的合作。
在我們這個世代有個共通點：幾乎家庭環境尚可的人，小時候都學過幾年鋼琴，當中甚至有人還考過了鋼琴六級八級的考試。而現在的我們似乎也有個共通點：幾乎沒有人再彈鋼琴，只有家里角落那個每到過新年才記得拂拂灰塵的鋼琴。
我自己也是個典型案例，從十歲學了四年鋼琴，直到被學業壓得喘不過氣終得停下來。直到出國念書、開始工作，生活和鋼琴再也構不著邊。但偶爾路過小酒吧，聽見里邊傳來悠揚的鋼琴聲，心里總是有點小小的遺憾，總覺辜負了當年那個坐在新買的鋼琴前雀躍、對音樂充滿憧憬的自己，幻想有天能翩翩地為家人演奏一曲。
相信很多人和我一樣，曾好幾次試著解除封印許久的鋼琴，卻又不知道如何開始。認五線譜和基本的知識還隱約在腦海，但技巧早已生疏，以往最熟練的曲子現在也彈得零零落落。對于現在的我們，彈琴早已不像當年，為了在生日會上獲取家人的掌聲。而是為了自己，下班后想坐下來，用音樂療愈自己疲憊的身心，彈首自己最有感覺的曲子。
某天我偶然在 TED 演講視頻中看到 一位德國鋼琴家的演講，他探討自己在生活中，當他在小酒吧里隨性的演奏一曲，總是很多人上前告訴他：他們小時候也學過琴，多希望自己能重拾鋼琴夢，和他彈的一樣好。他思考，到底是什么阻止大家繼續學琴，又是什么讓大家不愿重拾彈琴？
他總結了兩個原因：無聊的初學者練習曲和令人倍感壓力的鋼琴課
點擊鏈接，觀看 TED 演講：https://v.qq.com/x/page/b0860defswa.html
為了克服這兩個障礙，他和朋友開發了一款學琴應用 flowkey，集結了不少鋼琴老師編寫的課程以及鋼琴家的原創譜曲，讓各個鋼琴水平的人都能用自己的步調，享受和鋼琴音樂的片刻時光。
我對鋼琴課的回憶，總是那個氣質出眾但不茍言笑的鋼琴老師。想到要上每周的鋼琴課，就想到了自己還沒練熟早該練好的曲子，心中一陣緊張。但到了這個年紀，按時和鋼琴老師報到、每天花時間練習作業，總不符合現在的生活步調。
用 flowkey 應用自學鋼琴，就像用 App 學語言一樣。你可以先看看自己程度在哪，有哪些基本樂理需要復習，再依自己的步調跟著視頻循序漸進學習。每個視頻都只有不到五分鐘時間，很容易消化。當中有很多互動練習讓課程不枯燥，只要開啟麥克風，應用就會聽你彈得對不對。
這樣的自學視頻打開了學琴原本的屏障，只要下載應用、注冊帳戶，就算完全沒學過琴的新手，也可以踏出學琴的第一步。原本只想打開第一堂課程試試，但因為課程連貫有趣，不知不覺就把視頻全看完了！
無聊的初學者練習曲絕對是許多人對鋼琴卻步的原因，一想到要從無聊的練習曲開始，花費數月、甚至數年時間才能接觸到自己有興趣的曲子，就讓人想打退堂鼓。
但其實有很多好聽的曲子，只要找對樂譜，連初學者都能簡單上手。在 flowkey 應用內，你可以用水平篩選器，找到所有適合你彈奏的曲子。目前應用內有超過 1000 首曲子，除了古典音樂，所有曲子都是開發者團隊原創譜曲。
用戶可以像用 Spotify 聽歌一樣，隨意點選歌曲，先聽聽鋼琴音樂，如果喜歡這首曲子再點擊學習樂曲。我自己平時無聊就喜歡點選每首曲子來聽，聽到音樂那么優美自然就有了學琴的動力。
flowkey 曲目的總類特別豐富，從古典樂到流行樂、電影到動漫配樂，包括權力的游戲主題曲、Shallow 這些最受歡迎的曲子都能找到。樂曲更新速度也很快，會根據目前上映的電影或新出的專輯更新曲目。現在隨著應用翻譯成中文，曲目清單內還添加了亞洲流行，我們可以看到小幸運、追光者、千里之外等華語流行曲。
通過水平篩選器找到適合自己并且喜歡的樂曲類型
循環播放功能
每一首曲子中，你都可以隨意拖曳樂譜，選擇自己不熟悉的段落。視頻會反覆播放你所選擇的段落，直到你對自己得彈奏滿意為止。這個功能解決了很多人看視頻學鋼琴的困擾：你不需要重復點擊播放、暫停、再次重復播放。
拖拽樂譜，反復練習
等待模式
除了調整慢速練習模式，你也可以打開裝置麥克風、或直接用 Midi 連線電鋼琴，讓應用聽你彈奏的音調，判定你彈得對不對。如果彈錯音，應用會在原地等待直到你更正為止，就像個有耐心的老師給你實時反饋。
等待模式
單手模式
另外，每一首曲子，你都可以選擇以左手、右手分開練習。熟練后再切回雙手模式。
切換單/雙手模式
這個應用讓我在下載的第一天，就彈出了相隔多年的第一首曲子：A thousand years，是我本來就愛的西洋流行曲。
用 flowkey 練習 A Thousand Years
我很喜歡這款應用來自德國的教育理念：學習應該是發自對音樂的興趣和熱情，而非壓力。對于課程的編排、樂譜的品質、和所有輔助功能，都能看見開發者團隊的用心，和對于鋼琴教學的經驗。
最后，我非常推薦第一次接觸鋼琴、或想回頭學琴的你試試 flowkey 這款應用。你可以在 flowkey 官網 找到 iOS 和 Android 版應用的下載鏈接，或者直接通過網頁版開始練琴。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
