I really wish gitea offered a paid plan for individual users so that there was a good alternative to Github available for personal private git hosting without having to self host.
2,555 karma · joined October 29, 2012
It's crazy because YouTube has probably more information about the sort of products that I actually want to buy than probably any other company besides Shopify. About a quarter of what I watch are literally just product reviews. They have a ton of high-intent purchasing signal for reputable products, and instead they are showing me ads for trash. I know it doesn't have to be this way, because Instagram somehow manages to show me highly relevant ads for stuff that I've actually gone on to purchase after discovering there.
https://github.com/WebAssembly/stringref/blob/main/proposals...
If you want to be able to write the plugin in JavaScript, you have to take the AST from Rust and convert it to a JavaScript data structure in order to pass it into the plugin and then you have to convert the output back into a Rust data structure on the other end. Or you have to provide a JavaScript API that can safely mutate a Rust data structure from JavaScript while converting primitive values each way on demand. This is exactly like the problem I described with my Markdown processor. There's a ton of overhead involved, and it can cancel out a depressing amount of the performance gain that you would otherwise get from moving things to Rust.
Ultimately, these build tools need to have some degree of programmatic extensibility, and people want to get that without having to write their domain-specific logic in Rust and recompile the whole binary. There needs to be a better extensibility story and a cheaper (ideally, zero-copy) way to share data across the language boundary.
One of my projects (https://markdoc.dev/) is a Markdown dialect that supports custom tags and a React renderer. I recently experimented with implementing a parser for it in Rust in order to increase performance. My Rust-based parser is significantly faster than my existing JavaScript parser, but then I have to serialize the AST in order to move it from Rust to JavaScript. I'd like to implement the entire processor in Rust, but I need to let users define custom tags in JavaScript, and the overhead of going back and forth is far from ideal.
I'm hopeful that the recently-ratified Wasm GC proposal—which introduces managed structs and arrays that don't cost anything to pass between the Wasm environment and JavaScript—will help a lot. But it's going to take awhile for Wasm GC features to land in LLVM and be properly supported in Rust.
It's pretty remarkable how much faster and cleaner the Godot developer experience is compared to Unity. I feel like a spend a huge amount of my Unity development time waiting for the compiler and fighting with the tools. In Godot, the development iteration loop is much faster. I can't really speak to 3D capabilities, but for 2D projects I'm totally sold on Godot and see no reason to ever go back to Unity.
As someone who wants to advocate for standards instead of frameworks in my org, the problem I have is that the standards process is moving too slowly to address very basic and obvious developer needs. For example, the fact that Web Components are registered in a global namespace is really inconvenient in a large organization where you have many different teams making a large number of components. Sure, you can work around this with a BEM-like naming scheme, but you shouldn't have to. There's a great proposal for scoped custom element registries by one of the Lit developers that would actually address this issue, but it's been sitting in a repo for years without any meaningful activity and there doesn't appear to be any momentum around implementing it. Meanwhile, this is a thoroughly solved problem in the React and Vue ecosystems. That's just one small example, there are a ton of other papercuts and annoyances that there's no hope of fixing in the foreseeable future if solving them is going to involve a years-long slog through the standards process.
The DOM part spec that emerged from Apple's template instantiation proposal has the potential to provide an extremely efficient standards-based target for React-like frameworks that would solve a lot of the performance problems, especially if it's used judiciously for just the dynamic parts of the page in conjunction with server rendering and declarative shadow DOM. But nobody seems to be working on making that a reality, activity on that spec is pretty much dormant. React is going to keep winning until the standards furnish comparable ergonomics.
I'm a heavy Raindrop user and have been extremely happy with the service. I don't really use the social features, though.
AsciiDoc gets a lot of things right, but it also has a lot of syntactic complexity and idiosyncrasies that were challenging for our documentation contributors. In documents with structural complexity, it becomes unwieldly very quickly. For example, having to vary the length of the delimiter line when nesting delimited blocks[1] is pretty arcane and leaves a lot of room for errors to creep in when reordering pieces of content. Even though AsciiDoc's extensibility model was compelling to us, it's really not designed for the kind of deeply-nested hierarchies that we needed to be able to express things like our integration builder[2] UI.
Anyhow, we have a section in our FAQ[3] that provides more context about why we didn't choose AsciiDoc. I remain a fan of AsciiDoc even though it didn't fully meet our needs, and Markdoc was definitely influenced by the things that we thought AsciiDoc got right.
[1]: https://docs.asciidoctor.org/asciidoc/latest/blocks/delimite...
The key advantage of using Markdoc instead of using Markdown with liquid or another string-based templating system that preprocess the content is that the tags and other custom syntax are a first-class part of the Markdoc format. The document parses to an AST and the individual tags can programmatically manipulate the content and document node hierarchy instead of just manipulating or outputting strings of text that are passed on to a Markdown processor.
I can't imagine that there's a business justification for this decision that is compelling enough to offset the long-term damage to .NET adoption and community trust.
The scope is somewhat different: Jekyll and Middleman are static site generators that provide a full stack for content publishing whereas Markdoc is a framework for processing Markdown content with custom tags and transforming it into the desired output format. Markdoc can be used inside of a static site generator or a custom documentation platform.
Markdoc's syntax and custom tags also take a somewhat different approach than many of the string templating systems that are commonly used in static site generators. Markdoc is not a preprocessor, the tags are treated as a first-class part of the markdown content, which parses into a data structure that can be statically analyzed, programmatically transformed, and rendered into the desired output format. For us, that's React, but it could be raw HTML, Web Components, a slide deck, or whatever else you might come up with.
For every egregious user-hostile behavior, you can search and find a ton of forum threads where people discuss at length how to reverse or mitigate them. The fact that Microsoft is aware of this and continues to prioritize this kind of abusive growth hacking over user trust, knowing fully how that impacts the company's reputation among enthusiasts, is perhaps more damning than the actual practices.
Nobody at Microsoft who has decision-making authority actually cares. Contempt for the users is so deep in the DNA that this will never get better. It's disappointing, because it ultimately undermines all of the great effort that people elsewhere in the company have put into features like WSL that might otherwise make the platform attractive to modern developers.
It creates a really adversarial posture between the user and the platform. When they introduce new features, I'm reluctant to even try them because I don't trust their intentions. It's like being in an abusive relationship.
A mobile application that can't be shipped on iOS has a much lower total addressable market, which potentially makes it so that it isn't a commercially-viable undertaking for the developer. When I was working in the mobile space, I saw more than one great idea that never advanced to a product because of this factor.
There are also a lot of cases where a cross-platform mobile developer will kill an otherwise promising feature because they can't ship it on iOS and don't want to fragment their product by having different feature sets on each platform.
The dependency graph includes a lot of crap, like packages containing trivial single-line functions like "is-object" and "is-stream". That's a very large attack surface considering the poor security practices in the npm ecosystem[0] and the growing frequency of attacks on transitive dependencies[1].
I'm interested in hearing from the creators what steps they take to audit their transitive dependencies in order to prevent this application from being compromised. Given that a tool like this would typically be given privileged access to internal data sources, it seems like a tempting target. I don't think I'd be comfortable using this in production.
[0]: https://www.bleepingcomputer.com/news/security/52-percent-of... [1]: https://news.ycombinator.com/item?id=28962168
When they restricted access to their APIs and began tightening the screws to discourage third-party client development, Twitter began to stagnate because they no longer had a steady flow of new ideas to exploit. It also prevented third parties from providing the kind of user experience improvements and specializations that heavy users with large audiences relied on to make Twitter manageable. Without these things, the platform has deteriorated badly.
It isn’t surprising that they have circled back around to where they started and realized that they need third-party developers, but given how poorly they have treated the very people who drove Twitter’s initial success, I can’t imagine anybody is foolish enough to give them a second chance.
All of the effort that Microsoft has put into things like WSL and Docker integration to make the platform compelling to web application developers is undermined by these tactics. I'm getting really tired of playing whack-a-mole with all of the shady growth hacking that is built directly into the operating system. It bothers me enough that I'm ready to either switch to a Mac or go back to Linux.
This is great to hear, thanks for responding. I'm looking forward to seeing the Next.js dependency story improve in the future as you are able to complete that migration to swc. And hopefully Vercel's leadership in this space also encourages similar improvements in the broader node and react ecosystems.