Show HN: FlyCode – Git-Based Copy and Translations Editor for Web Apps (flycode.com)
Over the last six months, we’ve been building FlyCode, a product editing DevTool. We make it easy for team members to edit product copy in web and native apps’ code through FlyCode’s dashboard with auto-generated PRs instead of using a code editor.
From the beginning, we built around the belief that codebase ownership should stay with developers and that tools should flexibly coexist with a codebase rather than dictate infra changes. The key shift for us was to identify ways to include non-technical teams as individual contributors in the development process.
At FlyCode, we’re building a git-based product editor that makes it easy and safe for non-developers, to contribute to web & native apps code without actually coding. So far we’ve built [1]:
1) A GitHub application that scans your selected repositories in real-time for product copy. We are working on integrations to support GitLab and BitBucket in the future.
2) Editing React, Angular, and Vue code as well as JSON and gettext PO files (for international use-cases). We support editing product copy in resource files and hardcoded.
3) Pre-built GUI to invite your team to manage and edit product copy with auto-generated PRs.
We are hoping to use this post as an opportunity to collect feedback from fellow hackers! Our open beta is fully self-service and takes about 5-10 minutes from sign up to first edit [2]. We recently added 3 demo repositories so anyone can try the platform [3]. If you’re using GitLab or BitBucket sign up to be notified when FlyCode is ready for you.
We are far from our vision but the team - 10 amazing humans (we’re hiring developers [4]) - is working hard every day to improve the user experience and feature requests from our early collaborators (editing images, variables, JSON configuration, A/B testing, etc.).
While the platform is still in “beta”, we are confident that today’s FlyCode creates significant value for teams, large and small. Your feedback is what guides us forward so please share any questions, comments, or concerns in the comments below.
Join our (new) community on Discord [5] and follow us on Twitter [6]
Feel free to contact me at: jake[at]flycode.com or fly[at]flycode.com
[1] https://docs.flycode.com/ [2] https://flycode.com/developers [3] https://github.com/flycode-org [4] https://flycode.notion.site/Jobs-FlyCode-94d9cdf269794c368ce... [5] https://discord.gg/sKc4rZnMuw [6] https://twitter.com/FlycodeHQ
54 comments
[ 0.48 ms ] story [ 95.1 ms ] threadAs a compilers enthusiast for more than a decade, it is marvelous how analyzing and manipulating code has become more accessible in recent years and the possibilities it unlocks... very excited to empower teams to make edits for real web apps and save their developers time.
Feel free to contact me as well at: etai[at]flycode.com
Now, Roslyn ins't news anymore :) We have source generators in C#, and we not only have more main stream compiler plugins & annotation processor in Java and Kotlin (that spends a lot of time on their compiler API).
The same process has happened for the JavaScript ecosystem. The AST revolution has hit the frontend/JS ecosystem big-time. Tools like Babel (and derivatives like jscodeshift and recast) have democratized analysis and transformation of code bases. I urge you to play around with ASTExplorer to see how vast is the support for getting a proper AST for source-code.
Another big factor is the maturity GitHub marketplace. Today, smaller teams are able to ship production-ready apps for GitHub as the APIs have stabilized and are much documented than a few years ago.
All these together makes code-editing products much more feasible than a few years ago. It's not that AST and source editing novel ideas did not exist it's just they matured enough that you can actually build a product that targets a big enough segment of the market.
Opening the gates made by code for non-developers has always been a passion of mine.
The problem of editing web apps’ texts by non-coding team members has been a real pain for all of the companies I’ve been involved with in the past.
As an avid reader of HN, I’m always excited to share projects I’m involved in.
Feel free to contact me as well at: iddan[at]flycode.com
Thanks, Flycode; you guys rock.
When editing texts in the code it identifies each instance of the text as a separate text for now, It currently lists the text with the file it found them for texts in the code and with key for texts from JSON.
We also helped some clients with performing an automated component mapping to add additional context.
Text is the ground-floor for us - if you have other use-cases you'd like us to productize that will create value for you please shoot me a note jake[at]flycode.com
The quality of the design blows my mind as well, for a startup. It reminds me of GitHub's landing page, which I saw someone effusing about the other day on here: https://github.com/home
Signed up and saw extraction can take several days — is this done manually? I assumed scanning would be done purely automatically but I can see why there would need to be a manual review component.
The scan is 100% automatic and performed live - There might have been a small config issue, once fixed your system would be up and running in minutes :)
We would be happy to help, you can contact us:
- our support at support[at]flycode.com
- or me directly at etai[at]flycode.com
We'll be happy to help!
It seems like FlyCode does a better job integrating with Github. Is there anything else that's different from the TSM feature-set?
The main differentiator for us (going forward) is that we plan to support editing more than just text: images, configuration (like constants in the code), links, variables, etc.
The main difference between our current version and TSMs is FlyCode can edit texts inside the code whereas TSMs allow you edit texts in external files (JSON, PO) but not inside the code. Often times teams don’t want to lose the ability to search for texts inside the code just to support localization.
With FlyCode you can edit their texts in the primary language (e.g. English) inside the code and texts in other locales in a JSON file. FlyCode is editing texts inside Git allowing teams to run CI on the changes to the copy and make sure they're delivered safely to production, which reduces the integration cost and doesn’t introduce new points of failure. If FlyCode is down (worst-case scenario) you can still edit the texts inside Git just like any other part of the code.
> FlyCode identifies all the text segments in your product
I'm dubious of this claim to be honest. Identifying JSXText is one thing, but does it handle when you have UI text in props? How does is distinguish labelColor="red" from label="Username", if at all?
FlyCode is treating multiple locales as a first-class use-case. Some of our major customers use FlyCode for managing multi-locale applications. As for identifying all the text segments: what you are saying is true. For our beta we limited the text identification for JSXText only (for the React use-case) but we are certain we can identify more editable text in props using well-known names, looking into their type-defs or letting devs define which props should be exposed. This type of feedback and demand from our users that will bring our support to the next level!
Like many creators we are trying to apply the Pareto principle [0] and make most of the copy of apps editable now. I agree the phrasing “FlyCode identifies all the text segments in your product” could be improved.
[0]: https://en.wikipedia.org/wiki/Pareto_principle
I have couple of questions.
1- Does the company have short-term and long-term distribution strategies?
2- Can you tell us why you think that it’s a great idea?
- besides for supporting BitBucket and GitLab we plan to:
- Improve our editing experience by introducing more context from the UI
- Integrate with platforms like Linear and Jira
Great idea
- our main focus is creating value for our users.
- We believe that most of the great ideas come directly from the development community, which is why we are continuously collecting feedback and revalidating our assumptions.
> if the format is hardcoded, the name of the component in which the text resides would be the title
So it's component based tracking, though inside-component is hard to form context (e.g. line/column tracking won't work) even if you have AST of javascript. When code changes, AST changes (tree nodes tracking won't work either).
Interesting approach not to use hole like `{{ }}`.