labelflow
swc
Our great sponsors
labelflow | swc | |
---|---|---|
11 | 139 | |
242 | 29,773 | |
0.0% | 1.3% | |
0.0 | 9.9 | |
about 1 year ago | 6 days ago | |
TypeScript | Rust | |
GNU General Public License v3.0 or later | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
labelflow
-
Major product update: LabelFlow, the open platform for image labeling
https://github.com/Labelflow/labelflow/.
It is launch day for us at LabelFlow, the open platform for image labeling, would be great to get your feedback on this major update for us.
-
What are good alternatives to zip files when working with large online image datasets?
We are hosting image datasets on our platform and until recently the stored datasets were relatively small (several hundreds of images, few GB) so we only offered the possibility to export zip files containing images and labels in the COCO or YOLO format. As the average size of the datasets is growing, it's not convenient anymore to export a zip.
-
esbuild – An extremely fast JavaScript bundler
SWC in NextJS is still in canary with experimental settings, but it took me 3 lines of code yesterday to make it work on a fairly large app ( https://labelflow.ai ). Hot reload times instantly went from 10s to 1s. Twitter discussion here https://twitter.com/vlecrubier/status/1448371633673187329?s=...
Overall I’m pretty bullish on Rust tooling and integration within the JS/ Wasm ecosystem !
- Show HN: Labelflow: The open platform for image labeling
-
[Discussion] What is your go to technique for labelling data?
Check labelflow.ai. It's free, the code is published, web UI is super simple and the images do not need to be uploaded on remote servers so you get started in no time. For classification you would press the 1 key if image has hotdog else right key to go to the next image. Not gonna lie, you're going to need a bit of time for 10k images but definitely doable alone on a simple use case like that. To be fully transparent, I work there! Classification features are still in beta they will be released in 2 weeks. Happy labeling!
-
Storybook: UI component explorer for front end developers
I’ve used storybook for 4 years in teams of 1-15 devs and I’d say it’s a must have for any serious react app with 3+ full time developers. It has its rough edges sure but the ROI is 10x nonetheless in my experiences.
Advantages
- Testing components in isolation forces some good practices and allows to keep the codebase in check by encouraging good practices (limited coupling of unrelated parts of the codebase
- It’s super productive because it is both a form of unit tests, useful during development of UX in « TDD mode », and a very good documentation of your UI components. It greatly reduces the effort needed for both these aspects.
- For DX, the hot reload is generally faster in storybook than in the App (except if you use vite/snowpack in your app, so far..) because reloading a single component is faster than reloading the whole app and its state. In a large CRA our hot reload could sometimes take up 1min in complex cases, while storybook was taking 3s.
- Coupled with Chromatic (their hosted platform) and its GitHub integration it makes QA and visual regression testing a joy, 10x faster than alternatives, I really recommend that.
- It allows to share/iterate easily your ongoing developments with non-tech people in your organisation at early stage. A very good bridge between Figma and the final UI. A good support during Daily meetings about UI, just shared the deployed story url to ask for feedback.
Drawbacks
- It has its own Webpack config. So if you have a custom Webpack config in your app (don’t do that anyway, unless absolutely necessary) then be prepared to duplicate the customizations in your storybook config
- Global React Contexts needs to be duplicated in your storybook config and, if necessary, configured for individual stories. For example if your signup button changes based on an Auth status stored in a global context, then you will have to use Story.parameters to customize the content of the Auth context.
- We had a couple instances where storybook was the limiting factor for us to embrace some new/fancy tech, like yarn v2 or service worker. However maybe that’s a good litmus test: things that storybook support are state of the art JS and generally safe to use. Things that storybook does not support out of the box will cause you problems with other tools anyway: if it’s not storybook, some other tool like Cypress, Jest, Next, or some browsers will cause you trouble with your “shiny new tech”
- It can be slow to startup. We had a storybook with 300+ complex stories and it took 5min to startup and 10min to build in the CI
- It had some API changes/ migration pains a couple years back. However I think the new API is very good and will last a long time so this is behind.
Overall I definitely advocate to use storybook, especially with Chromatic, the ROI is 10x. If you find yourself limited by it in 2021 despite configuring it, maybe question your own tech stack.
Don’t try to implement your own storybook copycat (we had a colleague develop an alternative https://github.com/remorses/vitro , but i think it was not worth the effort)
If you want to see a state of the art repo in NextJS that uses storybook extensively with some customizations, check https://github.com/Labelflow/labelflow/
-
[P] LabelFlow is live! The open image annotation and dataset cleaning platform
As a matter of fact, LabelFlow uses a service worker exactly to avoid sending your data to a server (your data is stored in the local service worker instead). The code of this service worker is there: https://github.com/labelflow/labelflow/blob/main/typescript/web/src/worker/index.ts . You won't find any privacy-defeating stuff in there. It's super simple.
swc
-
Storybook 8 Beta
First, we switched the default compiler for new projects from Babel to SWC (Speedy Web Compiler). SWC is dramatically faster than Babel and requires zero configuration. We’ll continue to support Babel in any project currently using it.
-
What is JSDoc and why you may not need typescript for your next project?
SWC
-
Implementing auth flow as fast as possible using NestJS
As the reference explains “**SWC** (Speedy Web Compiler) is an extensible Rust-based platform that can be used for both compilation and bundling. Using SWC with Nest CLI is a great and simple way to significantly speed up your development process.”
-
Ruby Outperforms C: Breaking the Catch-22
This is specifically about breaking the myth that performing expensive self-contained operations (e.g, parsing GraphQL) in a native extension (C, Rust, etc.) is always faster than the interpreted language.
The JS ecosystem has the same problem, people think rewriting everything in Rust will be a magic fix. In practice, there's always the problem highlighted in the post (transitioning is expensive, causes optimization bailouts), as well as the cost of actually getting the results back into Node-land. This is why SWC abandoned the JS API for writing plugins - constantly bouncing back and forth while traversing AST nodes was even slower than Babel (e.g https://github.com/swc-project/swc/issues/1392#issuecomment-...)
-
Building a Minimalist Docker Image with Node, TypeScript
Why Speedy Web Compiler ?
- TypeScript Is Surprisingly OK for Compilers
-
FTA: Fast TypeScript Analyzer
FTA is a TypeScript static analysis tool built on the speedy foundations of swc. FTA is fast; capable of analyzing more than 150 files per second on typical hardware, it offers a powerful addition to your code quality toolkit.
-
Show HN: Ezno, a TypeScript checker written in Rust, is now open source
Very cool! I'm curious, is this intended for dev tooling?
For example, I could see this (or something similar) being useful as the engine for a typescript language server that would be faster than the standard one
But if it's not aimed at 1:1 with tsc, would it be intended more for something like swc[1]?
Or what would you expect people to use this for, besides just being a cool project to learn from?
-
[AskJS] Advantages of Rollup over other bundlers for creating libraries?
Rollup is highly configurable via plugins. It also supports a wide range of transpilation targets. However, it's written in JavaScript (well, TypeScript) so there's a ceiling on how fast it can go. esbuild and swc are orders-of-magnitude faster than Rollup.
-
Optimize your Bundle Size with SWC and GraphQL Codegen
There was already a Babel plugin for the client-preset for projects using Babel in the client-preset package. Now, as SWC itself, and Next.js is becoming more popular and uses SWC as its default compiler, there was a need for a SWC plugin as well. SWC is a fast and modern JavaScript/TypeScript compiler written in Rust, so the Babel plugin couldn't be used.
What are some alternatives?
esbuild - An extremely fast bundler for the web
vite - Next generation frontend tooling. It's fast!
ts-loader - TypeScript loader for webpack
tsup - The simplest and fastest way to bundle your TypeScript libraries.
vitest - Next generation testing framework powered by Vite.
ts-node - TypeScript execution and REPL for node.js
sucrase - Super-fast alternative to Babel for when you can target modern JS runtimes
create-react-app-esbuild - Use esbuild in your create-react-app for faster compilation, development and tests
react-ssr-starter - 🔥 ⚛️ A React boilerplate for a universal web app with a highly scalable, offline-first foundation and our focus on performance and best practices.
Rollup - Next-generation ES module bundler
create-react-app - Set up a modern web app by running one command.
parcel - The zero configuration build tool for the web. 📦🚀