整合营销服务商
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
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小时内与您取得联系。
