8 điểm bởi GN⁺ 2025-06-19 | 1 bình luận | Chia sẻ qua WhatsApp
  • Scrappy là một công cụ làm phần mềm kiểu homemade giúp cả người không chuyên cũng có thể dễ dàng tự tạo các ứng dụng nhỏ
  • Khác với các ứng dụng thương mại lớn hay ứng dụng enterprise, nó cho phép tự do giải quyết những vấn đề nhỏ mang tính cá nhân và sáng tạo
  • Cung cấp UI dựa trên canvas, chỉnh sửa mã đơn giản, cùng khả năng cộng tác và chia sẻ theo thời gian thực để cả người không biết lập trình cũng có thể sử dụng
  • Mọi ứng dụng (Scrapp) về mặc định đều là môi trường nhiều người dùng, có thể dùng và cộng tác ngay mà không cần tạo tài khoản
  • Khác với AI sinh mã hay các công cụ hiện có, Scrappy nhấn mạnh vào việc người dùng tự thao tác và quyền sở hữu

Giới thiệu và bối cảnh

  • Phần lớn phần mềm hiện nay tập trung vào bán cho thị trường đại chúng hoặc các ứng dụng tùy biến quy mô lớn
  • Nhưng những ứng dụng nhỏ, cá nhân hóa để đáp ứng nhu cầu thực tế của từng người lại rất hiếm
  • Scrappy là một nguyên mẫu nghiên cứu giúp bất kỳ ai cũng có thể tự tạo những ứng dụng đơn giản và sáng tạo cho bạn bè và gia đình
  • Mục tiêu của Scrappy là đưa ra một tầm nhìn cụ thể để nhiều người hơn có thể tạo ra phần mềm sáng tạo và cá nhân hóa, ngay cả khi không có chuyên môn lập trình

Scrappy là gì

  • Ứng dụng được tạo bằng Scrappy được gọi là Scrapp
  • Một số ví dụ tiêu biểu:
    • Ứng dụng luyện số học cho học sinh tiểu học: có thể điều chỉnh độ khó
    • Bộ đếm người tham gia sự kiện địa phương: quản lý lượt vào ra ở nhiều cổng
    • Đồng hồ tính chi phí cuộc họp: tính chi phí cuộc họp theo thời gian thực
    • Quản lý việc nhà theo tuần: có thể linh hoạt sắp xếp lịch cho từng thành viên

Trải nghiệm tạo ứng dụng trong Scrappy

  • Scrappy cho phép đặt các đối tượng như nút bấm, ô văn bản trên một canvas vô hạn tương tự Figma, Miro, Google Slides
  • Có thể chỉnh trực tiếp thuộc tính trong bảng Inspector, và cũng có thể gắn mã JavaScript vào các thành phần như nút bấm
  • Quá trình tạo ứng dụng được hoàn thiện dần bằng cách lặp lại từng bước kéo/thả, sửa thuộc tính và chèn mã

Tính năng chính:

  • Thiết lập hành vi cơ bản: đặt trường và nút rồi kết nối hành động ngay lập tức
  • Công thức phản ứng: triển khai thay đổi thuộc tính theo thời gian thực để phản hồi các điều kiện cụ thể
  • Đồng bộ nhiều người dùng: trạng thái luôn được lưu và đồng bộ theo thời gian thực
  • Chỉnh sửa trực tiếp: luôn có thể sửa theo thời gian thực mà không tách biệt giữa chạy và chỉnh sửa
  • Chia sẻ chọn lọc: có thể chia sẻ và liên kết riêng chỉ một phần cụ thể của ứng dụng
  • Thao tác dữ liệu trực quan: có thể xem dữ liệu như spreadsheet để debug và chỉnh sửa

Vì sao Scrappy được phát triển

  • Scrappy gắn với các xu hướng như lập trình do người dùng dẫn dắt, “small computing”, “casual programming”, “home-cooked software”
  • Khác với lập trình trực quan truyền thống (khối, node-wire), nó chọn hướng kết hợp thao tác trực quan và scripting
  • Lấy cảm hứng từ HyperCard, Visual Basic, các phương tiện trực tuyến đồng thời, đồng thời coi trọng trải nghiệm của các công cụ năng suất dạng canvas và cộng tác thời gian thực (Google Docs, Figma, v.v.)
  • Scrappy khác với các ứng dụng thương mại quy mô lớn hay cách tạo ứng dụng tự động bằng AI, ở chỗ người dùng trực tiếp kiểm soát và tối đa hóa tính cá nhân hóa, niềm vui và sự sáng tạo
  • Ngay cả khi không tự viết mã, nó vẫn mang lại trải nghiệm tạo ứng dụng dễ hơn và thân thiện với con người hơn.

Người dùng mục tiêu của Scrappy

  • Người tối ưu hóa quy trình công việc: những ai muốn cải thiện luồng công việc phức tạp mà không cần nhờ chuyên gia
  • Giáo viên và học sinh: có thể tập trung vào bản chất của lập trình mà không bị phân tâm bởi kỹ năng phụ trợ (command line, cấu hình môi trường)
  • Nhà phát triển theo sở thích: những ai muốn nhanh chóng khám phá nhiều dự án mà không vướng độ phức tạp của ứng dụng đại chúng
  • Người theo tinh thần DIY: người muốn tự tay làm ứng dụng riêng cho ngôi nhà, sở thích hay nhu cầu cá nhân

Hiện tại, để một người hoàn toàn mới tự tạo ứng dụng bằng Scrappy vẫn còn khó khăn (vẫn cần một phần kiến thức JavaScript), nhưng việc chia sẻ và remix thì cả người không biết lập trình cũng có thể làm được.

Những ứng dụng nào phù hợp để tạo bằng Scrappy?

  • Chia sẻ với bạn bè/người quen: phần lớn Scrapp phù hợp cho cộng tác thời gian thực giữa nhiều người dùng
  • Sửa đổi và cải tiến liên tục: có thể chỉnh ngay cả khi ứng dụng đang chạy, không cần quy trình deploy/build
  • Tính toán hoặc thao tác quy mô nhỏ: phù hợp hơn với tài liệu chia sẻ + một chút xử lý tính toán hơn là hệ thống phức tạp
  • Giảm ma sát cho người dùng: có thể truy cập và sử dụng chỉ bằng liên kết, không cần các bước thừa như tạo tài khoản
  • Nhóm người dùng nhỏ đáng tin cậy: không phù hợp nếu cần kiểm soát quyền hạn hoặc mức độ mission-critical

Ví dụ ý tưởng ứng dụng: flashcard tùy biến, agenda cuộc họp, quản lý workshop trực tuyến, bảng thông báo gia đình, kế hoạch du lịch, v.v.

Scrappy vs ứng dụng đại chúng

Khi không tìm được ứng dụng phổ biến phù hợp, bạn có thể tự làm rồi chia sẻ bằng Scrappy. Lợi ích của Scrappy:

  • Chỉ có những tính năng cần thiết: không có yếu tố thừa
  • Dấu ấn cá nhân: ứng dụng tự làm có ý nghĩa hơn và tạo cảm giác gắn bó hơn
  • Dễ sửa theo cách thú vị: có thể tự do trang trí màu sắc, bố cục và thêm yếu tố hài hước
  • Dễ remix/chia sẻ: người khác có thể dễ dàng sửa đổi và tái sử dụng
  • Thiết kế lấy cộng tác làm trung tâm: nhiều người có thể cùng thao tác và chỉnh sửa đồng thời
  • Dùng ngay lập tức: chỉ cần nhấp liên kết là dùng được ngay, không cần đăng ký tài khoản
  • Quyền sở hữu dữ liệu rõ ràng: dữ liệu được lưu cục bộ nên người dùng kiểm soát hoàn toàn

Scrappy vs tạo ứng dụng bằng AI

AI có thể tự động tạo ứng dụng, nhưng điểm mạnh của Scrappy nằm ở khả năng dễ hiểu, cộng tác thời gian thực và cảm giác sở hữu sáng tạo

  • Cấu trúc dễ hiểu: dựa trên các đối tượng trực quan thay vì mã phức tạp
  • Hỗ trợ hợp tác thời gian thực: nhiều người dùng có thể cùng cộng tác và chỉnh sửa
  • Nhiều niềm vui và sáng tạo hơn: mang lại phản hồi tức thì và niềm vui khi chủ động chỉnh sửa

Scrappy vs HyperCard và các công cụ kế nhiệm

  • Chia sẻ thân thiện với Internet: ứng dụng Scrappy có thể chia sẻ trực tuyến chỉ bằng liên kết
  • Môi trường cộng tác thời gian thực: hỗ trợ chỉnh sửa/chạy đồng thời
  • UI và tương tác hiện đại: canvas vô hạn, hỗ trợ nhiều loại đối tượng
  • JavaScript scripting: dùng ngôn ngữ hiện đại và phổ biến
  • Nhiều đối tượng tương tác đa dạng hơn: hỗ trợ chuỗi, số, ngày tháng, JSON, v.v.
  • Công thức phản ứng và liên kết trạng thái: có thể thiết lập quan hệ động tương tự spreadsheet

Kế hoạch sắp tới

  • Giảm rào cản tiếp cận cho người dùng không phải lập trình viên
    • tự động hoàn thành mã, debug dễ hơn, trực quan hóa quan hệ, thông báo lỗi dễ hiểu, trợ lý dựa trên AI
    • chia sẻ nhanh và dễ hơn, gallery công khai, tăng cường hỗ trợ di động
  • Tăng cường và mở rộng tính năng
    • tăng cường collection và xử lý dữ liệu, quản lý đối tượng lặp lại, đưa vào reusable component
    • mở rộng khả năng của Scrappy (hỗ trợ đối tượng mới), cải thiện tính nhất quán về khái niệm, v.v.

1 bình luận

 
GN⁺ 2025-06-19
Ý kiến Hacker News
  • Tôi thích định hướng của dự án này, nhưng muốn chia sẻ trải nghiệm rằng mô hình SaaS được host sẵn không phải thứ tôi muốn. Với các dự án một ngày như bộ đếm nhỏ thì không sao, nhưng nếu là một ứng dụng nhỏ dùng trong nhiều năm thì mức độ phụ thuộc trở thành vấn đề. Dù đường cong học tập có thấp đến đâu thì nó vẫn tồn tại, và tôi lại muốn một lựa chọn có tính tiếp cận lâu dài, ngôn ngữ dễ dùng, và công cụ cho phép tự gắn GUI hơn. Tôi không nghĩ mã nguồn cần phải bị che giấu hoàn toàn; nó nên được làm dễ để mọi người thực sự có thể tự làm theo hướng đó. Chỉ cần nhớ lại đã có bao nhiêu người học CSS nhờ MySpace thì thấy rõ: bắt đầu bằng copy-paste, nhưng rồi cuối cùng họ vẫn tinh chỉnh thành của riêng mình. Cá nhân tôi dạo này chủ yếu dùng HTML/CSS/JS, và nếu thật sự cần backend thì dùng PHP thuần (không framework). Cách này có nhược điểm là bị trói vào trình duyệt, nhưng ở công ty tôi, những dự án nhỏ làm theo kiểu này (bao gồm cả AutoHotKey) đã chạy ổn hơn 10 năm mà hầu như không cần bảo trì. Đặc biệt, tôi đã ngừng đụng đến script AutoHotKey từ 8 năm trước khi chuyển sang macOS, nhưng đồng nghiệp vẫn dùng chúng nhiều lần mỗi ngày. Ngay cả khi AutoHotKey ngừng hoạt động thì mã đã tạo vẫn có thể tiếp tục dùng. Trong khi đó, các giải pháp kiểu SaaS có rủi ro là nếu người sáng lập chuyển mối quan tâm sang thứ khác thì bạn lại phải làm lại từ đầu. Điểm cốt lõi là những người tìm các giải pháp “scrappy” như vậy không muốn phải làm lại mỗi lần như thế.

    • Nếu là kiểu giải pháp này thì tôi nghĩ cách làm giống TiddlyWiki sẽ phù hợp hơn. TiddlyWiki chứa toàn bộ web app trong một file HTML duy nhất, và trước đây khi thay đổi gì đó thì nó lưu ngay vào chính file HTML nên có tính tự sao chép. Gần đây còn hỗ trợ lưu qua backend và nhiều cách khác. Với file HTML tự sao chép và quyền truy cập backend tùy chọn, đây có thể là một lựa chọn đáng tin cậy hơn nhiều cho các dự án cá nhân nhỏ, tùy biến theo nhu cầu. Ít nhất thì khả năng phục hồi mạnh là một ưu điểm lớn.
    • Đề xuất codeboot.org. Đây là một Python IDE hoàn toàn chạy phía client, có hỗ trợ single-stepping, hệ thống tệp ảo phi phân cấp, FFI với mã JS và nhiều tính năng khác (xem tài liệu). Việc chia sẻ app cũng rất dễ: chỉ cần nhấp phải vào nút play rồi copy URL là xong. Tôi đã dùng nó để giải quyết nhiều vấn đề như làm sạch dữ liệu, và thường bookmark luôn các app tạo theo cách này để dùng. Nó thực sự hoạt động tốt, và nếu ai tò mò thì AMA (cứ hỏi). Nó đang được phát triển tích cực và còn có các tính năng mới rất hay sắp ra mắt.
    • Tôi nghĩ cũng có thể đảm bảo khả năng dùng lâu dài bằng cách công khai toàn bộ mã của SaaS dưới dạng mã nguồn mở. Penpot đang áp dụng cách này rất tốt. Phần lớn mọi người dùng nó như SaaS, nhưng cũng có thể self-host. Tất nhiên, các yếu tố như chứng thực bản phân phối hay ký ứng dụng thì khó là điều không tránh khỏi, nhưng có lẽ cách kiểu Web3 cũng có thể giúp. Hoặc cũng có thể như PICO-8 hay Flash ngày xưa: công khai runtime rồi phân phối “cart” hoặc app. Xây dựng một kênh phân phối đáng tin cậy bên ngoài SaaS khá phức tạp, nhưng vì trong lịch sử đã từng có tiền lệ nên tôi nghĩ đáng để thử. Tham khảo Penpot / PICO-8
    • Với tư cách là đồng tác giả của Scrappy, tôi hoàn toàn đồng tình rằng khả năng sử dụng phần mềm lâu dài là rất quan trọng. Scrappy được thiết kế theo kiến trúc local-first, không có backend truyền thống, nên phần phụ thuộc vào cloud chỉ là máy chủ đồng bộ đơn giản. (Sau khi cuộc thảo luận này bùng lên trên HN, chúng tôi đã vội thêm chi tiết kỹ thuật vào FAQ.) Tôi nghĩ đây là điểm khác biệt cả về kỹ thuật lẫn tài chính so với các công cụ low-code/no-code kiểu SaaS. Ngay từ đầu, chúng tôi đã thử nghiệm tính năng lưu scrap thành file HTML tự chứa, một trang duy nhất, nhưng hiện tính năng này chưa được đưa ra công khai.
    • Tôi đang làm mấy thứ kiểu này bằng Cursor và phong cách vibe coding, và thật sự rất hài lòng. Gần đây tôi làm một trình theo dõi máy bay nhận dữ liệu đường bay gần nhà qua SDR, gắn thêm thông tin chuyến bay từ sân bay, rồi hiển thị lên magic mirror theo kiểu bảng lật ở ga tàu. Tôi gần như không biết gì về frontend JS, nhưng sau khoảng 10 tiếng code đã hoàn thành một app khá ổn. Nếu là trước đây thì chắc phải mất hơn 2 tháng rồi cuối cùng bỏ cuộc, nhưng với vibe coding thì trải nghiệm rất vui và tích cực. Nó cỡ khoảng 1200 sLOC, và tôi dám nói là mã ở mức bán chuyên với logging/hiệu năng/chất lượng khá tốt (theo tôi còn tốt hơn mặt bằng mã thương mại trung bình).
  • CardStock không được nhắc trong bài gốc nhưng có vẻ có mục tiêu và cách tiếp cận khá giống Scrappy. Khác với Scrappy, CardStock là mã nguồn mở và chạy được cục bộ. Tham khảo CardStock / kho GitHub. Decker cũng là mã nguồn mở, và đã triển khai sẵn nhiều yêu cầu trong roadmap của Scrappy (ngôn ngữ truy vấn dữ liệu bảng · widget lưới, trừu tượng hóa bộ phận thành “Contraption”, v.v.). Xem Decker.

    • Tôi đã tìm một công cụ như thế này từ rất lâu rồi, nên việc CardStock có ứng dụng desktop thực sự là điều rất có ý nghĩa.
  • Dù roadmap có nói sẽ làm cho app tạo trên di động hoạt động tốt, nhưng có vẻ chỉnh sửa ngay trên di động thì không nằm trong kế hoạch (có nhắc rằng “màn hình cảm ứng cỡ lòng bàn tay gây khó chịu khi chỉnh sửa Scrapps”). Nhưng hiện nay nhiều người chỉ dùng di động như thiết bị điện toán duy nhất, thậm chí còn viết code hay tiểu thuyết trên đó. Vì vậy, tôi muốn nhấn mạnh rằng nếu suy nghĩ cả về giao diện chỉnh sửa trên di động, dù hơi bất tiện, thì tác động của công cụ này sẽ lớn hơn rất nhiều.

  • Một trong những việc tuyệt nhất tôi từng làm là dành một tuần tạo một app đơn giản để đưa dữ liệu đi bộ từ Apple Watch lên một tấm bản đồ lớn duy nhất, rồi đưa lên AppStore và chia sẻ với người quen. Sau một năm, bạn bè và cả những người tình cờ thấy app vẫn đi bộ khắp thành phố rồi nhắn xác nhận cho tôi, khiến tôi rất tự hào. Không có doanh thu nhưng đó thực sự là một trải nghiệm đầy ý nghĩa. Như OP nói, làm những app đơn giản cho bạn bè vì niềm vui là một trong những hạnh phúc lớn nhất.

    • Tò mò muốn xem link app.
    • Thử tưởng tượng xem để làm ra nó phải vượt qua bao nhiêu bức tường và vô số rào cản, sẽ thấy rất nhiều người đã bỏ cuộc ở một trong số đó. Kết cục là người dùng vẫn không kiểm soát được gì và lại bị khóa vào nhà cung cấp. Nếu có thể ra lệnh trực tiếp cho AI rồi tự do chuyển sang một chiếc đồng hồ mã nguồn mở thì thế giới đó sẽ tuyệt biết bao.
  • Tôi chưa từng thấy môi trường lập trình nào thực sự hữu ích cho end-user bằng spreadsheet.

    • Ví dụ cực đoan cho hướng này thì đề xuất pyspread.
    • Cá nhân tôi bỏ qua vì không có test, kiểm soát phiên bản và hỗ trợ thư viện.
    • Cuối cùng thì học code trực tiếp vẫn tốt hơn. Tôi không hiểu lý do phải học những công cụ này. Với lập trình viên thì cứ tự làm là xong, dùng LLM thì mấy thứ rất đơn giản có thể vibe coding rất nhanh mà chẳng mất gì. Ngay cả với người không phải lập trình viên, tôi cũng không biết thực sự có bao nhiêu người sẽ học các công cụ này (tò mò TAM là bao nhiêu). Tôi nghi ngờ chuyện ai đó lại muốn kéo-thả app để tạo nó.
  • Vibe coding chưa thể thay thế lập trình viên ngay, nhưng với các hệ thống đơn giản kiểu này thì nó sẽ là đối thủ mạnh nhất. Chỉ cần bảo LLM tạo một app đơn giản (HTML+JS nhúng), chỉnh chút là ra bản hoàn thiện, thậm chí còn đẹp hơn về mặt hình ảnh. Xem ví dụ.

    • Tôi cũng đang làm side project bằng vibe coding. Cứ vài tiếng là lại gặp một vấn đề mà LLM không giải được, nên tôi nghĩ người không có kinh nghiệm code có thể sẽ hoàn toàn không vượt qua nổi. Chắc còn tùy công nghệ dùng và phạm vi dự án.
    • Báo lỗi: nhập kiểu 3 + 2 = 5.1 vẫn được chấp nhận là đáp án đúng.
    • Vibe coding đúng là mục đích gốc, và họ là đối thủ tự nhiên của nhau.
    • Tôi tò mò về một stack hệ thống đơn giản có thể self-host. Cá nhân tôi cần Vue với xác thực, DB offline nhiều người chơi, static hosting, file hosting, và tính năng lọc để người dùng không xem được dữ liệu của người khác.
    • Tôi muốn đổi dấu hỏi thành chỗ trống hoặc gạch dưới.
  • Chúng ta đang tiếp cận chủ đề này từ góc nhìn lập trình viên, nhưng tôi nghĩ cơ hội thực sự nằm ở cộng đồng. Ví dụ có thể bắt đầu như một app store cá nhân cho gia đình (kiểu Masterson). Không cần bảo mật vì toàn người quen, và cũng không thể đóng góp nếu không có lời mời. Chỉ là nêu một ý tưởng vậy thôi.

  • Nếu phải kéo-thả các thành phần UI lên một tờ trống, rồi liên tục vật lộn vì grid snap không khớp với kích thước phần tử UI, và cuối cùng vẫn phải nhập JavaScript thuần mà không có tự động hoàn thành mã, không có lập trình trực quan, không có trợ giúp API, không có hỗ trợ AI, thì tôi tự hỏi đây có thật sự là đích đến cuối cùng không.

  • Tôi cũng đồng ý 100% với cách tiếp cận “component có thể script” thay vì dạng block cho người mới bắt đầu. Tôi đang ở trên di động nên sẽ thử trên desktop sau. Điểm còn thiếu trong phân tích là mọi người muốn “chia sẻ dễ” và “zero-cost”. Ngay cả trong môi trường tối giản nhất, việc tự làm app vẫn dễ, nhưng phân phối (rào cản App Store)/hosting mới là vấn đề, nên ngay cả gia đình hay người quen cũng ngần ngại bỏ ra 5 USD mỗi tháng. Thực ra lập trình viên chuyên nghiệp cũng vậy thôi.

    • Self-host bằng web server ở nhà + dynamic DNS là được.
    • Tôi thích ý tưởng chia sẻ nói chung, nhưng hosting/phân phối miễn phí có rủi ro bị người dùng xấu lạm dụng.
  • Khi thấy các định hướng kiểu “máy tính phải làm việc cho con người và nên trở thành hoạt động của mọi người như nấu ăn hay xử lý văn bản”, tôi thấy nó hơi quá chung chung. Các câu kiểu “có live update, hoàn toàn miễn phí. LLM sẽ…” với quá nhiều em-dash (-) khiến tôi nghĩ ngay đến nội dung do AI tạo. Cá nhân tôi là kiểu nếu nhận ra nội dung do AI viết thì hứng thú tụt rất nhanh. Không phải lỗi của người tạo, nhưng bản thân tôi cũng không hứng thú lắm với kiểu copy như vậy.

    • Kiểu em-dash như vậy là văn phong IRL tôi đã dùng suốt 10~15 năm nay. Bản thân tôi cũng không thích tiêu thụ nội dung do AI tạo, và nếu ai đó chỉ gõ prompt thì tôi cũng thấy tốt hơn là tự hỏi trực tiếp LLM.
    • Nếu xét cách dùng hyphen/en-dash/em-dash thì dùng em-dash như dấu ngăn cách thật ra là cách đúng theo nguyên tắc. Tôi không đồng ý với việc coi đó là dấu hiệu của AI.
    • Với tư cách là đồng tác giả Scrappy, tôi là người dùng Macintosh lâu năm nên phân biệt rất rõ hyphen, en-dash, em-dash :) Tôi chỉ thỉnh thoảng dùng AI để polishing, tuyệt đối không dùng để sinh văn bản. Chính vì tự viết nên khối lượng công việc thực sự rất lớn (phần lớn công việc thực tế do Pontus đảm nhận).
    • Nếu muốn gõ em dash thì dùng compose key rồi gõ dấu gạch nối ba lần. — kiểu như vậy. Trên Mac thì là shift-option-hyphen.