PyScript is a Pythonic alternative to Scratch, JSFiddle, or other "easy to use" programming frameworks, making the web a friendly, hackable place where anyone can author interesting and interactive applications.
CodeEdit is a code editor built by the community, for the community, written entirely and unapologetically for macOS. Features include syntax highlighting, code completion, project find and replace, snippets, terminal, task running, debugging, git integration, code review, extensions, and more.
Not subscribed to Console? Join thousands of engineers, VCs, and early-stage CTOs in subscribing to a weekly roundup of the latest in open-source software, curated by an ex-Amazon engineer
Hey Austin! Thanks for joining us! Let’s start with your background. Where have you worked in the past, where are you from, how did you learn how to program, and what languages or frameworks do you like?
My story starts at age 14 in Houston, Texas when my parents asked if I’d like to learn how to create a website for their photography business. My interest in computers at the time drove me to gladly accept. I thoroughly enjoyed the process of learning, even more than video games, and as a kid that’s saying something.
Because it was a photography website they wanted me to build, it needed to be designed well in addition to making it work. Throughout my career, I have always strived to maintain both design and development skillsets. After completing their website, friends of the family saw my work and asked if I could do the same for them and their business. That was the beginning of my freelance business that got me through high school. One of my clients later hired me on to work an internship in my junior year of high school and later, after I graduated, a full-time role that kick-started my career.
I did not attend college. I considered going, but I was already continuously learning new things and I was always able to find something that made me more than enough to support myself with. I felt like it was almost redundant to spend a small fortune to get a piece of paper telling others that I can do what I have always known how to do, especially when they are willing to hire me without it.
As I started designing websites, the languages I started with were HTML, CSS, and some minor Javascript and PHP. Embarrassingly enough, I started in Dreamweaver and Flash. It was the hot thing to use at the time and I am so glad to see that trend turn into something far superior.
I have since landed jobs for fortune 500 companies like Intuit, USAA, Ancestry.com, and Verizon.
Currently, my languages and frameworks of choice are Javascript/Typescript with React.js and Next.js for web experiences and Swift and SwiftUI for native macOS and iOS apps.
Who or what are your biggest influences as a developer?
Throughout my career, my biggest influences have changed. It started with close mentors and coworkers, but quickly became those I surrounded myself with and interacted with online.
I have constantly compared myself to the best of the best, not in a bad way but more so as a means to stay motivated to be my very best self as a designer and developer. I thrive on inspiration from those around me. I never copy others' work, but I am inspired by everything I see. I am truly astounded by the awesome work that is being done in the community every day and look forward to contributing what I can.
It has always been my ultimate goal to “make a ding in the universe” as Steve Jobs most accurately put it.
What's an opinion you have that most people don't agree with?
It’s okay to fail. Failures are what make you better. It is through failure that you learn from your mistakes which make you that much better the next time you try. If we did not see failure we would never see success.
That said, I am also of the opinion that we should strive for perfectionism at all costs. Without someone to drive exceptional design and development practices that inspire others, you tend to see a lot of corners being cut which leads to a failed product. Users of your work are begging to be delighted by what you produce. If you are not doing that, then users will quickly lose interest, and you are left with a lackluster product at best. Even if it is something small that doesn’t get seen by many people, it still deserves the most attention you can give it to make it special. Attention to detail can never be understated or unjustified if you want to produce a product that will turn heads.
What’s your most controversial programming opinion?
I asked a coworker to answer this about me. Their answer was, “You are not satisfied unless it’s done in the way that you think is right, and the problem with that is you’re usually right.”
Both from a design perspective and a development perspective, I make a strong effort to keep things maintainable, scalable, and efficient and I am consistently pushing my team, both in my open source project and at work, to carry those same objectives in the work that they produce.
What is your favorite software tool?
Most recently I have discovered Raycast. It is an excellent productivity booster and Spotlight replacement that has incredible potential. The team that works on Raycast is doing a phenomenal job, particularly around their extension architecture which focuses on a great developer experience. It is not only developed well but the design is absolutely exceptional. These are all goals we aspire to with CodeEdit.
If you could dictate that everyone in the world should read one book, what would it be?
All designers and developers should look at these great handbooks put together by the awesome team at InVision. They also come in audio form and are all free which is nice.
If you had to suggest one person developers should follow, who would it be?
Elon Musk. He has an excellent model for success (though sometimes not the most conventional) that I strive to follow.
If you could teach every 12 year old in the world one thing, what would it be and why?
Interested in development? Get involved in open-source projects early. You will be exposed to developers of all different backgrounds, workflows, and coding practices. I wish I had at a much younger age.
If I gave you $10 million to invest in one thing right now, where would you put it?
I’d invest in today’s youth by starting a free and easy to access platform for young aspiring programmers to learn and grow with the community.
If I gave you $100 million to invest in one thing right now, where would you put it?
I’d invest in and give back to the open-source community and put money into the innovative projects that need it the most. I’d also find new ways to grow the community to help accelerate innovation.
What are you currently learning?
I am always learning something new. Swift and SwiftUI are still relatively new to me with my background in Javascript and web-based applications. Some concepts have been completely foreign to me given that background but it is refreshing to learn new things.
How do you separate good project ideas from bad ones?
It all hinges on bringing value to the user. If value can be proven and enough people can get behind an idea then it’s good. If it doesn’t provide value or it is not extremely realistic, then it is not. Traditionally value can be proven by profit or revenue, but in our case, working on an open-source project we measure value by GitHub stars, rate of contribution, and once launched, user feedback and rate of adoption.
Why was CodeEdit started?
I’ve used and seen many code editors and IDEs in my career in software development ranging from highly integrated solutions with awful user interfaces to lightweight solutions with available extensions so you can make what you want out of it. Like many developers, I've been using VS Code. As a Mac user, I found the UI to be very inconsistent with the patterns that I have come to love in macOS as it is a product from Microsoft. Moreover, the biggest concern is with performance.
VS Code and a few other editors use Electron, developed by Github with the release of Atom. I’ve always been a big fan of Electron as it allows me as a developer of web-based applications to easily expand the applications I write to the desktop, which is huge. That said, when developing an application that demands high performance, Electron is unable to allow you to take full advantage of system resources. This is because Electron is essentially a web view running on an instance of Chromium which as we know has huge performance issues. It is so easy for organizations to justify the sacrifice of speed and performance in favor of increased multi-platform compatibility, but ultimately this ends up hurting the end-user especially as more and more apps move to Electron. This destroys system resources and is very irresponsible from a software point of view in my honest opinion.
I’ve always thought, what if there was an editor that was developed natively on macOS and had a UI that was designed in such a way that was consistent with the patterns its users have come to love?
At first, I played around with theming VS Code and made it feel close to a native macOS app through the use of a Vibrancy extension and a lot of custom CSS. Ultimately it was a lot of work for little return.
A while ago I created this macOS Settings concept in Figma and wrote a Medium article about it. So I started building some components for designing macOS applications in Figma. I decided to start a design concept using these components that explores how a code editor would look if it followed Apple’s design patterns. This concept was the result.
It came to a point where I couldn’t just sit on this idea, I had to do something with this. I had the idea to reach out to a few people on Twitter. As I shopped the idea around, I could quickly gather that this was something the community was interested in. I had the idea to start an open-source project and get as many as I could to help with it.
As soon as I started the project, it grew like wildfire! Within a week of it being live, it grew to almost 5k stars and was the top trending project on GitHub for three days straight!
I was slammed every day responding to messages on our Discord server, reading and replying to issues, and reviewing PRs waiting to get merged. There were a few highly involved contributors that I enlisted to help me with these responsibilities so we could move the project along faster. (Lukas, Marco, and Jason are three that come to mind first) We continue to see tremendous progress at an extraordinary pace, something that you just will not see if developed by a company with a team of a handful of even dedicated people.
Where did the name for CodeEdit come from?
As we are using Apple as our goal post, we wanted to use a name that they might have come up with themselves. I thought about Xcode and considered a derivative of that, but that didn’t feel right. Then I thought about Apple’s application naming conventions. They use very simple names to convey to users what the app does without even having to open it. Photos, Music, Mail, Calendar, Pages, Numbers, etc. I also considered TextEdit and how lightweight it is. People use it all of the time to edit small files when they don’t want to open a word processor or IDE to do a simple edit. So instead of “Text”Edit, I thought to replace the word “text” with “code” because that is what is being edited, and the name “CodeEdit” came about. It just felt right. It felt very consistent with Apple’s naming convention so it stuck.
Who, or what was the biggest inspiration for CodeEdit?
Apple. We aspire to design and develop CodeEdit as if Apple themselves were doing so. That is the lens by which we make every decision in this project.
We use Xcode as a guide with a few exceptions because that is the pattern that Apple has set to edit code and develop apps.
Are there any overarching goals of CodeEdit that drive design or implementation? If so, what trade-offs have been made in CodeEdit as a consequence of these goals?
With CodeEdit we are heavily focused on experience and keeping it close to Apple, but also considering our users. We understand that most of our users will probably not be using it for Swift development because Xcode should be used for that, so we most likely will need to deviate slightly from the Apple path in regards to our extensions architecture because we want to maximize extension developer adoption. This will mean that our API and the extensions built that use it, will be written in Javascript which is arguably much more common when compared to Swift. To not sacrifice performance, we are looking to use React to render native views right in CodeEdit rather than extensions rendering in a web view.
What is the most challenging problem that’s been solved in CodeEdit, so far?
It’s got to be our extension architecture. We are proceeding with extreme caution and being slow and methodical in our planning because you want to design an API that will last and won’t change on our future extension developers.
Are there any competitors or projects similar to CodeEdit? If so, what were they lacking that made you consider building something new?
There certainly are. VS Code, Nova, Atom, Sublime Text, Webstorm, and Fleet are among the top competitors. Here is a quick breakdown:
VS Code: Free, open-source, uses Electron – not native
Nova: Paid, closed source, native
Nova comes close to aligning with our goals in being native to macOS, but there are a few things that hold it back from its potential in my opinion.
It’s paid, which will greatly decrease user adoption and its extension developer base
It is native, but Panic seems to want to add their own design “flair” to their apps so it loses that macOS vibe in many ways.
Atom: Free, open-source, uses Electron – not native
Sublime Text: Antiquated, developed in Python
Webstorm (and all other JetBrain IDE’s): Paid, closed source, written in Java
Fleet (Beta): Paid, closed source, written in Kotlin
See “Why was CodeEdit started?”
What was the most surprising thing you learned while working on CodeEdit?
How well it was received by the community! (See “Why was CodeEdit started?”)
What is your typical approach to debugging issues filed in the CodeEdit repo?
Reproduce the bug → Identify the problem → Work towards a solution → Test to verify the fix → Have it reviewed → Merge.
If necessary we discuss the problem in the issue the bug is being tracked in if the solution requires a little more collaboration.
What is the release process like for CodeEdit?
Because we are in early development, we do not have one as of yet. However, we will have an alpha release soon and a beta release shortly after.
For versioning, we plan on using the typical SemVer pattern. Once we release version 1.0.0 we will move to iterative staged releases, with Alpha, Beta, and Stable/Production releases similar to Chrome and VS Code.
Users will be able to specify their preferred release stage to get updates for the application preferences.
Is CodeEdit intended to eventually be monetized if it isn’t monetized already?
No. We specifically say in our project README and later on our website that we are open source, free forever. I never got into this for financial gain. This is built by the community, for the community. It wouldn’t be fair for me to profit from the great work that is being done by so many talented developers out there.
That being said, we do have a sponsorship page. We will incur expenses as the project progresses and we want to be prepared for that (hosting costs, promo material, intro video, ads, CI/CD, etc.). We’d encourage anyone who is interested in the project and is able to, to please sponsor us. Your contribution will be put to good use!
How do you balance your work on open-source with your day job and other responsibilities?
When the project began, I found it increasingly difficult to manage as this project grew. I was staying up long hours each night to make sure I got to everything that needed to be done was taken care of all on top of my normal responsibilities at work. Eventually, I got help from some of the most consistent contributors which has helped greatly and I am so happy to see people step up and chip in where there is a need.
Do you think any of your projects do more harm than good?
Sometimes I think “Am I in over my head?”, “Am I wasting people's precious time?”, “Am I fragmenting the space by introducing yet another editor?”, I quickly turn this kind of doubt into motivation that I can use to work even harder so I see this project to success.
What is the best way for a new developer to contribute to CodeEdit?
Just jump in! Join our growing community on Discord. Read our project README and contributing guide. Check out our GitHub issues and our project board to see where we are and what you might be able to pick up. We label easy tasks with “good first issue” if you want to start by getting your feet wet. If you have any questions at all, please ask. There are tons of community members ready and willing to help you get started!
If you plan to continue developing CodeEdit, where do you see the project heading next?
It can only grow from here. We are heading up so many worthwhile efforts like building a custom code editor view and architecting an extension API focussed on DX that developers looking to extend CodeEdit can use.
What motivates you to continue contributing to CodeEdit?
Comradery in the community, being part of something bigger than yourself. The feeling of building something that people love using, and use to support themselves or build their next big idea. It can’t get much better than that.
Are there any other projects besides CodeEdit that you’re working on?
I currently work for a global church on an internal financial tool that helps them to manage donations across bank accounts associated with each congregation around the world. The application I build helps them to report on and reconcile issues with this data. It is built using React.js and Next.js.
Do you have any other project ideas that you haven’t started?
I have many, but I also unfortunately have very little time to execute them. One idea I’ve had is an app that will intelligently help and facilitate the recruiting and hiring process, enabling hiring managers to find more accurate candidates and job seekers to find the roles that will fit them best. Perhaps one day I can pursue this idea further, or maybe CodeEdit presents an opportunity in some form that has yet to present itself, time will tell.
Where do you see software development heading next?
SwiftUI will continue getting better, making it easier for developers to write what they need to.
Where do you see open-source heading next?
Open source continues to improve year after year. Github pushes new and better tools to enable better organization and faster development. It can only get better from here!
Do you have any suggestions for someone trying to make their first contribution to an open-source project?
Be patient with yourself and be humble. There is a lot to learn, but you need to be open to fresh ideas and new ways of thinking about things. There is a lot of fish in the sea that is the open-source community but don’t feel overwhelmed. You can make a difference and everyone’s contribution is valuable, big or small. Starting small is good, then you can start picking up bigger issues as you get more comfortable.
Want to join the conversation about one of the projects featured this week? Drop a comment, or see what others are saying!
Interested in sponsoring the newsletter or know of any cool projects or interesting developers you want us to interview? Reach out at console.substack@gmail.com or mention us @ConsoleWeekly!
One last thing! Interested in more open-source newsletters like Console? Check out Open Pull Request on Substack!
