HN user
If you feel like it, you can add this page https://www.codingfont.com/AtkinsonHyperlegibleMono to your article, it is the dedicated page for Atkinson Hyperlegible Mono with the options to compare it to other fonts on the side by side view.
Ah, thanks for digging this out, this is the version 1, which I made using a no code tool. the current version is made using sveltekit, it is also just open sourced in the other comment.
This font was just added to codingfont a few minutes ago! https://www.codingfont.com/AtkinsonHyperlegibleMono you can compare it side by side to your other favorite coding font to see which one is better looking in a code editor! You may also play the blindfold game to see if it will TRULY wins against all others in a blind test on codingfont.com
The code was private but I see no reason not to open source it, so I just did! https://github.com/Typogram/coding-font-sveltekit This way you can add your own font to it, just modify codingfonts.ts and include the font files in the css!
This might be of interest for you: https://www.codingfont.com/ I made it to select the perfect coding font. i will update it to include the Atkinson Hyperlegible Mono soon!
Three Creative Workarounds for AI’s Limitations in Typography
Lean and mean could mean people lose their job, lead to talent churn in the job market, wasting their talent and time doing things they don't love. Keep a steady cushy job so these talent can make great product while enjoy their life is a net gain for society.
I think growing !== making your product last shorter. Develop a brand new market like AR VR headset is growing. Develop a new service that people need is growing. Keep growing to compensate for shrinking market for existing business, so that your employee can have a steady job and do what they love and are trained well to do, without churning in the job market is a net gain for society.
I hate to be THAT GAL, but... try Svelte! I love it more than Vue.
A joke or really? At this point, I would just port it into Svelte, it is the same amount of effort anyway and it has been so long!
The tldr; is that we see a lot of similar requirements from developers across Angular and Wiz, so we're looking for opportunities to reuse work. Good example is the Angular Signals library that's now used in all the YouTube Mobile Web. In a similar way, Angular is bringing more fine-grained code loading that Wiz offers.
It sounds no different from Svelte borrowing concepts from SolidJS, or Vue borrowing ideas from Svelte, from you said — if it is just adding some features that Wiz has, it doesn't sound like merging? Why put a shocking title that Angular is merging with Wiz, when Wiz has no name recognition in the outer dev community — like we don't know what that means?
Quote from my newsletter “Don’t Sell Your Indie Business to Digital Ocean!”:
The sad part of the story is that most of what happened can’t be traced easily. Domain redirect can be set up with a few clicks of a button, and soon enough, most people forget these indie blogs ever existed and what happened to them. I want to write down what I saw so that there is a record of what Digital Ocean has done or has not done.
Back in 2014, I turned to Scotch.io to learn AngularJS. Scotch.io offered clear and concise tutorials that were easy to follow, even for someone who was new to the framework. I saved many tutorial articles to my browser’s bookmark; as I don’t clean up my bookmarks, I still have them saved up in my messy bookmark folder today.
One day I dug up and clicked on a scotch.io article from my bookmark and was surprised to see that it returned a “404 page not found” error. After some research, it turned out that Digital Ocean bought scotch.io, so consequently, the scotch.io home page got redirected to Digital Ocean’s homepage, and articles like the ones I saved were removed.
What was my problem with that? I didn’t know where to begin. Redirecting a blog to a product page with no context was just intentionally wasting my time — why would a visitor of a blog not be surprised to land on “Try Digital Ocean for free for 60 days”? And the cherry on top? Not setting up a wild card page rule to redirect all scotch.io article links to Digital Ocean, hence why I got a 404 error — they can’t even do their evil with efficiency. They wanted to milk this cow dry but had a leaky bucket — the stupidity, the carelessness, the insult to the editor who spent years creating quality content. Also, wasn’t Digital Ocean a service to host websites? Setting up page redirects is literally part of their service, and what a demonstration they had put on!
The above was what I witnessed in 2022. As of writing this article in February 2023, Digital Ocean has fixed some of the issues. Now all links of scotch.io redirect to the Digital Ocean community, which at least hosts some tech content. The original blog articles of scotch.io are still missing from the Internet. I searched for the titles that were saved to my bookmarks and couldn’t find them, on the Digital Ocean community or elsewhere. It is as if they were never written.
What triggers me to write down these words above as “record” is that Digital Ocean bought CSS Tricks — another beloved tech blog — about a year ago, and recently they laid off the only editor of CSS Tricks. It is entirely possible that one day we will lose access to CSS Tricks content like “A Complete Guide to Flexbox” — a front-end “staple food,” a link that always shows up in purple in search results; and instead, we get to enjoy losing 3 seconds of our life being redirected and then bounce.
Some of you may think that Digital Ocean will treat CSS Tricks more nicely, and that they won’t take down its quality content written over a decade of time. CSS Tricks is much more famous and high-profile than scotch.io, after all. I wouldn’t be too sure because of what happened to coding-fonts.css-tricks.com — go ahead, click on it. It is broken and just redirects to another page.
I launched a similar project called codingfont.com back in 2021, which is a tournament-style game to pick the winner coding font. Chris Coyier, the founder of CSS Tricks, wrote about it, which brought massive traffic to my site (Thanks, Chris! I am grateful as a fellow tinkerer). The article mentioned that CSS Tricks had built their own coding font microsite. Fast forward to May 2022, less than two months after CSS Tricks got bought, the CSS Tricks microsite was broken, and someone reported an issue on Github. Chris, who would be in an advisory role according to the Digital Ocean announcement, answered quickly:
I’m afraid I’m not sure what Digital Ocean plans to do with it. I would, of course, vote for it to be re-hosted right at coding-fonts.css-tricks.com — and would be happy to help put it on Digital Ocean App Platform as well!
It was clear that Chris as an advisor wasn’t given any real access to decision-makers at Digital Ocean to make any difference in such a simple matter. It was such a simple and easy matter to solve that a bystander came forward and hosted the microsite somewhere else, ironically on Netlify — a competitor to Digital Ocean.
So there you go, another record I put down here in case Digital Ocean bothers to correct it one day, let the Internet remember that it had happened.
My open plea to Digital Ocean:
Stop this unethical business practice NOW! Your company buys these blogs to build a good reputation among the developer community, but clearly, the plan has failed. Instead, it hurts your brand, and I will never use your service. It is not too late to keep your promises — publish new content to the site, or at least keep the site alive and working as it is.
My appeal to other content creators: Don’t sell your indie business to Digital Ocean.
they screw us more than once already. CSS Tricks is not their first victim, there is also scotch.io, where I learn Angular stuff. One day I tried to visit a saved article in my bookmark, the entire site and all its subpage are gone, and just redirect to digital ocean. That is more screwed than CSS Tricks is today, all that content, puff, gone!
This is not the first time digital ocean did something like this. And unlike some other commenter here saying they only did it because CSS tutorials don't give them ROI, extra information here is that they also did it with javascript tutorials, like scotch.io, so I am leaning towards to that DO just do poorly with their investment regardless. I wrote more about their track record in buying indie dev blog and then kill them in my newsletter last year when CSS-Tricks's editor got laid off: https://build.typogram.co/p/dont-sell-your-indie-business-to
I think Chris pointed out a very key fact: running site like css tricks or scotch.io takes a special mix of skill, organically the site grows big with one or two person with that right mix of skills, but once big corporate bought it and for whatever reason didn't retain that talent, they have to replace it with a team, which kills the ROI.
Oh so true. Adobe also had a product that is the same concept as Webflow, called InFlow (if I am not mistaken), and killed it, before Webflow existed. Some of its employe went to work for Webflow.
They were not devastated or demotivated. The morale is still high from what I heard from the inside. 1B is 5% of the original deal. Without liquidating any equity, they can get 5% of the original payout, which is still large! (I think Dylan Field the CEO might do this, to make the team happy. I can imagine the outside investor being left out on this, since this is not a liquidation event, then even more “free” money for the team)
Also, they are not working on any Adobe roadmap. Other than a few offsite brainstorm session, no real work has been put into integrating with Adobe.
Thanks for letting me know! I added the extra link!
I see where you're coming from, but there are a few critical points about the Adobe-Figma deal that you got wrong. (I am an ex-Adobe XD employee)
When Adobe announced its plan to acquire Figma in September 2022, the timing was actually at the valley of startup valuations. The market was really down then. Since that time, the market has actually warmed up, not cooled down. This means if Adobe were to negotiate a deal now, it would likely cost them even more than what they agreed upon last year. Contrary to what you said.
Speaking of the negotiation, I think Adobe dropped the ball. They agreed to a whopping 20 billion dollars, which in my view was four times too high given Figma's real valuation at that time, especially considering the low market (I wrote about how I calculate this 5B valuation in https://typogram.co/build/on-adobe-acquiring-figma/). Then, with the deal being halted by regulators, Adobe still had to pay the full breakup fee, within just three days! It's kind of laughable how poor their negotiation strategy was.
About Adobe's product strategy, there's a bit of confusion. Firefly, their new thing, isn't even about UX tooling; it's more focused on creative AI. The real product that is actually relevant here is Adobe XD, which Adobe has just put on maintenance mode (since at least September). a change I noticed on their help page as recently as this September (https://helpx.adobe.com/support/xd.html#troubleshooting). This move is a huge strategic mistake. It's a clear loss of momentum for Adobe in the UX tooling space, making them even less competitive against Figma. Meanwhile, Figma hasn’t missed a beat and continues to surge ahead.
I’m an ex-Adobe employee who worked on Adobe XD, which is basically Adobe's answer to Figma. when Adobe decided to buy Figma, my first reaction was pretty much "Wait, what?" I wrote down my initial thoughts about it[^1], it felt like a losing situation all around - for Adobe, Figma, and all the designers out there. The only folks who really seemed to win were Figma's investors.
Now, let's talk how bad the breakup deal is for Adobe. You've got Elon Musk buying Twitter for a massive 54 billion, with a breakup fee of 1 billion if it doesn't go through. But then, there's Adobe, buying Figma for 20 billion, and they also get slapped with a 1 billion breakup fee. Musk tried to back out of his deal, no real reason, and didn't want to pay the fee. But Adobe? Their deal gets killed by regulators, and they still have to pay the full 1 billion. Makes you really think about the decision-makers' negotiation at Adobe, do they work for Figma?
Before the deal was sealed, Figma didn't start integrating their tech with Adobe’s. However, Adobe put XD on the maintaince mode[^2], losing market share since then. Yes, XD wasn't as cool as Figma, but it had its sizable share of big corporate users. The data backs this up[^3].
The whole fallout from this? For the design community and Figma, it's kind of a win. The CEO of Figma is pretty well-respected for how he treats his team. That 1 billion from Adobe might help out the Figma folks who got left in the lurch. Morale over there is still pretty high. But Adobe stopping development on XD? I think that was a misstep. I suspect they might have done that to please the regulators. Now put the team back together and continue development? That takes time for big machine like Adobe, spoken from my past experience. But I am happy XD get to live on, at least hopefully.
Here are the references I mentioned:
[^1]. My initial thoughts on Adobe acquiring Figma: [Typogram](https://typogram.co/build/on-adobe-acquiring-figma/)
[^2]. Adobe XD Enters Maintenance Mode: [Typogram](https://build.typogram.co/p/adobe-xd-enters-maintenance-mode)
[^3]. Design Tool Survey Report: [Survey 2022](https://uxtools.co/survey/2022/toolkit), [Survey 2023](https://uxtools.co/survey/2023/toolkit)
Not promoting my setup, but just to point out that 80 is a sensible default, and it is not based / targeted for ancient old rare setups.
People use ultrawide screen, with half screen dedicated to browser, half screen for code editor, and two columns open in editor. This is very modern setup, and 80 is perfect for it. Don't limit your thinking to your own setup.
I think discussion on the perfect limit on public forum is non-sense. It might be slightly less non-sense to discuss it with your team, but even that I think it is bike-shredding most of the time, unless the entire team for some reason (like they share the same equipment setup and happen to have same preference) overwhelmingly share the sentiment.
Do you work with a large team? There is no correct answer for formatting for a team, there is only correct answer for individual person. The line limit 80/120/160 will work for certain people with their setup, but not others. Stuff like using a ultrawide screen with two columns, or code on laptop screen with single column, or code with half screen code editor and half screen browser, etc, there are endless mutation, all of them can benefit from different settings. It is essentially not possible to find the best option for everyone on the team. You may think 120 is the best, but there is no way to prove it. It just worked for you because of your coding setup and preference.
Maybe essential is a better word.
Why not set a bounty to improve Prettier instead of building a competing project just to increase the motivation to improve Prettier?
There are three reasons, I think:
1. Writing a rust compiler is separate from prettier project because of its nature. Prettier is not written in Rust, and Rust has proven to be a robust option to write a formatter, so the goal really is to write a formatter in Rust itself, and it can't be replaced with improving prettier within its current codebase
2. Asking someone to write a Prettier-branded and owned Rust compiler for $20k is not enticing enough. It is essentially equivalent to contracting someone to write some code for Prettier, with an open bid. It would cost a lot more to hire someone to write these code. Great programmer who has the skill to answer this bounty get paid at least $200 an hour (extremely conservative estimate), $20k is enough for 100 hours of work for one person, not enough to finish the project. But getting rewarded for $20k for stuff you write and will own is enticing!
3. Good ecosystem going forward. If prettier owns the winner project, prettier is responsible to maintaining and improving it. The good that the bounty did ends when the project is handed over. Prettier team get burdened with a project that they didn't write themselves, and the original team (the best people for the job) is not incentivized to keep maintaining it. There is no ongoing competition to keep this field active.
Absolutely, I agree with you: using IndexedDB is cost-effective, and pushing cached user action data periodically to Firebase sounds like a solid strategy. Thanks for the insight!
In Svelte 4, the let counter = 0 syntax is already reactive by default, a feature enabled by the compiler. This has been the status quo for Svelte prior to the rune change. The introduction of the $state(0) rune actually provides more hints about its reactivity than before, and restore the original meaning of let counter = 0 (in rune mode). While it's true that the compiler's "invasion" into JS/TS syntax has been a point of discussion, this invasion has been happening for a while, and the initial shock wave has been well-absorbed by the community.
Interestingly, the new changes could be seen as a retreat from that initial invasion, likely triggering a different response from the community. In fact, the resistance I've seen (and my own as well) has been in the opposite direction—it's hating this retreat, complaining Svelte becoming less "magical." and more close to regular joe Javascript.
Hi Evan You! (Hi from wentin) It's great to see you here in this thread. It's such a wonderful gesture for the open-source community to collaborate in this manner, by sharing valuable lessons learned the hard way.
It’s intriguing to see where the Svelte exploration will lead. Will it face disapproval or achieve success? While I agree that both implementations have arrived at the same place (almost serendipitously), their origins differ. For Vue, it's about adding the syntactic sugar by dropping .value, making it less explicit and more magical. In contrast, Svelte made the change to make things more explicit and reduce the “black magicness” from the svelte compiler, and bring it more similar to javascript. This difference might trigger totally different reaction, time will tell.
Looking forward to more insightful discussions!
First off, thanks for chiming in with that detailed explanation. It's always a learning curve when you dive into the technical side of things, and I genuinely appreciate it.
Given the constraints with TypeScript not being further compilable, I've been pondering on Svelte's direction. Personally, I'd lean towards letting go of some of the special touches in js/ts file if it means keeping more magic in Svelte. If we're heading towards making Svelte syntax work exactly the same in js/ts entirely, it feels like we might risk turning Svelte from its unique language-like identity into just another framework in the JS world.
Thanks again for the insights! I have already felt a little better about my current work in migrating an app from another framework to svelte 4. I was worried that I have made a very wasteful decision for my own company.
One of Svelte's biggest advantages is its compiler, positioning it more as a language than just another JS framework. If I'm not mistaken, the compiler allows Svelte to define its syntax to anything they want.
Given this, I'm curious: couldn't the traditional syntax of `let counter = 0` be made to function similarly to the new let count = $state(0);? Transpile it to let count = $state(0) under the hood? If that can work technically, instead of introducing a new rune for reactivity, why not introduce a "negative" rune to denote non-reactive statements? This way, the change wouldn't break existing code; it would be more of a progressive enhancement.
I agree the move to unify the Svelte <script> tag with regular js/ts files is an improvement. It was indeed a little odd that certain syntactic sugar, like the $, would work exclusively within the Svelte <script> and not in a js/ts file that's right next to it. However, from what I gather, it seems the Svelte team is aligning the Svelte script more with js/ts, rather than bringing the js/ts closer to Svelte's unique syntax. This trajectory seems to be pushing Svelte towards resembling traditional JavaScript frameworks, like React. It's a departure from Svelte's unique strength of having a custom compiler and behaving more like a language. If every syntax in Svelte is expected to mirror its behavior in js/ts, eventually svelte will lose all it secret sauce that made it so unique. Why can't we add a rune into js/ts file, a note in the beginning to tell svelte compiler that this is svelte enhanced js/ts file, compile it like svelte script tag code? Bring js/ts more alike to svelte?
I was really hyped up by the beginning of the article, but it seems really miss the points with the conclusion.
I don't think it is easier to manipulate with the last two examples, and I am guessing no actual graphic artist has read this or play with this before you publish it. To think of ways to improve bezier curves for vector graphics, you need to fully contextualize your thinking about the use case; this is not an academic mathematical discussion after all. Based on my understanding, your finding has no mathematical value as Pomax pointed it out, it is not new, it is an old math with a few constraints that is pre-defined, based on your assumption of what graphic artist wanted most of the time, which I agree is a good direction.
I strongly suggest for anyone to try to make a better vector graphics tool, try to draw a letter S with the new approach as a test case, you can choose an existing font to match. And know existing vector graphics rules, here is a couple as example:
- add anchor points at the horizontal and vertical extrema of your paths
- control points should not cross path with one another
Curves that doesn't follow these rules are valid, fine mathematical curves, but graphic artists has practices this for years to rule out them as bad for the purpose of graphic design. Again, the goal is to find the more much smaller set of suitable curves from the infinite realm of mathematical possibilities, for the context of graphic design