TGTGInsightтелеграм анализLIVE / telegram public index
← Такты, стеки, два колеса
Обратно към каналите

TGINSIGHT SIMILAR POSTS

Намери подобно съдържание

Изходен канал @clockstackwheels · Post #32 · 29.05

Прегледай публикациятаВиж оригинала

Попробовал, наконец, разработку на Blazor. Это такой фреймворк под .NET, который позволяет писать фронтенд на C#. Работает он двумя способами: либо собирает весь проект в WebAssembly, и бедный пользователь грузит себе мегабайтную dll, либо устанавливает клиент-серверное соединение через SignalR и шлёт клиенту информацию об обновлённых DOM-элементах. Вот вторую то я и пробовал. Казалось бы — каждое нажатие кнопки требует отправить на сервер запрос и получить ответ. Никогда такого не было! Но субъективно разницы во времени отклика нет (потому что веб и так достаточно медленный, хаха). Фронтенд-часть пишется очень похоже на JSX: вёрстка реактивно вперемешку с кодом. Когда-то я очень ругал React за такой подход, потому что каша. Но нетипизированный JS по-умолчанию каша, а здесь же по факту получается очень удобно: статический анализ не даёт тебе делать ошибки и писать ерунду. Но приятный полноценный язык программирования вместо JavaScript это лишь вишенка на торте. Самое крутое — вся сила серверного кода с полноценной возможностью обращения к базе данных, шеринг моделей данных между сервером и клиентом, и, наконец, Dependency Injection любого серверного модуля в «клиент»! То есть вы не просто пишете одно приложение вместо двух, вы ещё и получаете отсутствие ошибок при каком-нибудь изменении моделей API, когда сервер стал отдавать не то, что ожидает клиент. Вам вообще теперь не нужен API, достаточно закодить нужную функцию на серваке и инжектировать её в нужный фронтенд-модуль. Это супер удобно, супер быстро, супер устойчиво к ошибкам. Теперь не хочется возвращаться даже на вполне крутой Vue 3. Но, система пока новая, она не обросла решениями от комьюнити, а браузерный API всё равно придётся дергать через JavaScript Interop. Для совсем кайфа нужно подождать годик, поскольку развитие идёт довольно быстро. Например, там нет очень нужного в таком деле hot reload, но в .NET 6 он уже анонсирован, и вроде как есть в превью, а релиз в ноябре. #dev

Hashtags

#dev
Резултати

Намерени 84 подобни публикации

Търсене: #nodejs

当前筛选 #nodejs清除筛选
Tomoko RD

@tomoko_channel · Post #705 · 10.10.2024 г., 12:24

Намери подобниПрегледай

Node.js 纪录片感想（小抄） 1. Ryan Dahl 创建 Node.js 当时流行的 Web 框架（如 Ruby on Rails）在处理高并发时效率不够高，特别是在处理 I/O 密集型任务时性能显得不足。虽然这些框架也支持异步 I/O，但用起来很别扭。 他也尝试过其他语言（如 Python、Lua、Haskell），但发现这些语言的运行时已经沉淀了多年，深受传统同步编程模型的限制，很难进行根本性的变革。 于是 Boy Meet Girl，算是终于让他看见了 Javascript 这个本身就在浏览器中天天需要处理异步场景的语言。（JavaScript 本身就依赖事件循环和异步操作来处理用户交互与网络请求。） 关键点是 easily build optimal server 以及 forcing them to only use async IO。也是 Node.js 的核心优势。 2. Isaac Schlueter 加入 & npm 的诞生 这点倒是没什么好说的，pip 比它要早一点，08年 vs 10年。 想起我大二那年，被 pacman 什么都能下载给震撼住了。真的是，生在这种什么都有的年代真是被惯坏了。不过即使我在那个年代，也不会造出这样的轮子吧 3. Joyent 买下 Node.js 这一阶段就是真的让 Node.js 成为一个企业级产品了，毕竟有公司去资助一批工程师去全职开发。 也是在这个阶段支持了 Windows，让用户量大大增加了。（通过实现 LibUV 库来处理 Windows 特有的 I/O 操作和事件循环，兼容了 linux 和 win 的操作） 4. Ryan 退出 & 社区分裂 Ryan 在 Windows 版本出来之后就腻了，看来是那种喜欢写新功能而不想全天在修 BUG 的人？于是负责人从 Ryan -> Issac -> TJ Fontaine。 至于创始人离开之后，社区的贡献者自然就觉得给 Joyent 打白工非常无趣，于是就去 fork 了 io.js（确实，虽然 MySQL 是开源的，但谁会乐意无偿贡献代码给 Oracle 呢？） 5. 基金会成立 最后是双方妥协，Joyent 将 Node.js 的管理权交给了基金会， io.js 和 Node.js 最终合并。可喜可贺，可喜可贺。 不过这也是社区力量占主导才能强迫公司妥协，不然就变成现在的 MariaDB 了？ --- (仅仅是笔记，不一定对，需要勘误) https://www.youtube.com/watch?v=LB8KwiiUGy0 #TIL#nodejs

Hashtags

#til#nodejs
AprilNEA's Notebook

@AprilNEALab · Post #75 · 31.08.2024 г., 14:44

Намери подобниПрегледай

#NodeJS#ORM 这么严重的问题花了一年才被修复。 https://github.com/drizzle-team/drizzle-orm/issues/724 https://github.com/drizzle-team/drizzle-orm/releases/tag/0.33.0 TL;DR Drizzle ORM 导致 JSONB 在 Postgres 数据库中错误的以 JSON String 表示

Hashtags

#nodejs#orm
123•••67
← ПредишнаСтр. 1 от 7Следваща →