I had a near identical approach for my blog but I recently moved to a headless CMS. The bugbear being that it wasn't easy to publish if I wasn't at my desktop. With a headless CMS, I auth through Github via my phone, which also serves as the draft/publish step since posts in the CMS manifest as pull requests. It's been working great so far, with the caveat that the writing experience isn't as nice as Obsidian.
FWIW the CMS is Decap CMS and I have it configured likewise with Cloudflare Pages (since Pages supports functions that are needed for the auth/callback cycle).
Emacs 29 made getting started a lot easier IMO, my from-scratch configuration is pretty minimal and I use it everyday. To plug my own project, I built a "kickstart" equivalent (https://github.com/mgmarlow/start-emacs) that sets up some recommended defaults and packages with lots of comments so you can easily extend it.
I don't think so. I just think right now Vercel is very good at marketing and lots of new programmers and hopping on the NextJS train. There are tons of materials out there for building apps quickly and it's very appealing for newer developers, particularly the bits where getting a site deployed is as easy as running a couple commands w/ the Vercel CLI.
For larger applications, I don't see meta-frameworks eating up a significant chunk of the world since they're very expensive to run in certain situations. Especially so if you use the default deployment options and rely entirely on serverless functions for your infrastructure or a database-as-a-service like Firebase/Supabase. I think it's inevitable that people will carve bits and pieces off of their meta-frameworks into different types of applications as they scale, just in the same way that people carve up their Rails applications of yore.
I generally think that the meta-framework obsession will also help propel backend SSR + HTMX, since thinking in server-side components is easier to translate to traditional backend SSR than SPA -> backend.
> database-as-a-service like Firebase/Supabase. I think it's inevitable that people will carve bits and pieces off of their meta-frameworks into different types of applications as they scale
(Supabase maintainer) Supabase is just postgres, so it’s actually designed like this. You can start using all the “auto generated” tooling, then evolve into a pure Postgres + middleware solution if you need/want to
> they're very expensive to run in certain situations.
In terms of pricing, it’s ~equivalent to RDS, at least the database component
I found this snippet in one of Mickey's earlier tree-sitter posts that works great. It does require searching through the tree-sitter repo to make sure your paths are correct:
Really happy to see this. I've been using Emacs 29+ for the past while and have enjoyed simplifying my configuration now that use-package is OOTB. I think now is a really excellent time to try Emacs if you haven't already.
I put together a simple tool to generate a starter Emacs config from a few configurable options, which I can now update to point at a proper release channel instead of a prerelease:
As someone learning Common Lisp for fun and planning to use it in the web, I’m a little disturbed by the “we manually force garbage collection periodically” part of that article. I haven’t fully digested the commentary, so maybe I’m more concerned than necessary…
Looks like they wanted to configure a much larger heap than they needed just in case, but then to have the system pretend it doesn't exist, and do GC cycles at a much lower threshold. I'm surprised SBCL doesn't have parameters to be just tuned that way; if not, that could be upstreamed.
Going longer between garbage collection cycles could be worse in terms of caching and paging. Marking the live objects allocated in that generation is about the same, since that doesn't grow, but there is more garbage to visit and sweep. Sweeping a smaller memory area more frequently is going to be faster than sweeping a larger area less frequently, from the point or view of caches and TLB.
(Regarding my remark about live objects; with larger collection cycles, they could be spread in a wider VM footprint, even if their quantity doesn't grow. The image has a kind of "GC working set"; longer intervals mean that there is a longer working set. The data being transformed cycles through more memory locations.)
I would say so, specially when you plan to use it for web dev (welcome!). Shinmera has released a game in CL heavily depending on CLOS (object system), and he says the GC is barely a matter.
I recognize your user name. Great work on the Lisp Journey site! Several times I’ve had a question and then found the exact same thought expressed on your site (along with an answer).
That's nice to hear, thanks for the feedback. I've been puzzled many times when starting out (or taking a not-so crowded path), so I'm glad the ones after me are having a better time.
Now, your time to build cool things and share in the process ;)
I use web-mode + typescript-language-server for React+TSX. Whether or not you choose to use eglot or lsp-mode, I'd still recommend following the lsp-mode performance guide: https://emacs-lsp.github.io/lsp-mode/page/performance/. Those tips are useful for all setups.
For me its been the questionable stewardship of vscode (https://github.com/omnisharp/omnisharp-vscode/issues/5276) driving me away from vscode and the Emacs from Scratch videos from the System Crafters youtube channel driving me towards Emacs. When I was looking for alternatives I stumbled on those videos and they blew me away.
Also Emacs 28/29 has been way more welcoming and easy to get started with than when I first tried 8 or so years ago.
How people expect anything else from a huge corporation is mind-boggling to me. They open source something and people think they are being alturistic. Just like android. You start with open source, then move more and more things behind the corpwall.
Emacs is free and is free for life.
Also Davids channel is most excellent. There's a discord channel where people are very friendly and helpful as well.
It's kind of funny seeing how every few years we'll have a new hot editor, and all the people who convert to those editors will wonder why anyone would still use Emacs or Vim, only to find out a few years later why people continue to use these 30+ year old editors.
In the meanwhile, both Vim and Emacs will incorporate the functionality that originally made the new editors popular, so the long time Emacs and Vim users lose almost nothing, did not have to go out of their way to use a new editor, and continued to benefit from the existing advantages of these editors.
I don't necessarily think that anyone was expecting anything else, it's just that VS Code is a great free tool, so even if you know it's probably going to go downhill over time it's hard to deny its effectiveness currently.
I mean it's free, it comes with it's own compilers and toolchains, it's a lot easier to pick up than vim or emacs or even IntelliJ (that's just got a much more dense UI), so it's become the standard IDE for students. Then, once you've gotten your degree or your training or whatever, you'll probably want to stick with the tool you know.
People like David from System Crafters and Prot are definitely doing a lot to bringing Emacs backs to the masses. They are a visible manifestation of the technical (and media) quality of part of the community. I do not think they get enough credit.
Depends on what you're gonna be doing with it. If you're mainly working with HTML, CSS, maybe some Bash scripts, you can just open it up, work your way through the (IMO excellent) tutorial and you're off to the races.
That said, if Emacs gets its claws in you you may, like me, lose a fair few evenings and weekends just playing around with various packages and customization options because it's just so fun to tweak.
If you install Doom Emacs [1] after installing Emacs itself, I think it would be a couple of days. At least if you can live with the things Doom comes with. It's just a matter of following the instructions, uncommenting the relevant modules in .doom.d/init.el, syncing the changes and off you go.
System Crafters youtube channel driving me towards Emacs
I really don't get how watching a PM-type struggle with emacs for two hours at a spell is compelling or instructive. I can struggle with emacs all by myself.
> I really don't get how watching a PM-type struggle with emacs for two hours at a spell is compelling or instructive. I can struggle with emacs all by myself.
Because it's a lot scarier to struggle alone. Plus as his videos progress and his knowledge progresses he frequently teaches you things that come up and practice a lot as a matter of course.
It's kind of like when you start programming you have to build up your endurance for feeling like you're always in a dark room feeling around... and you convince yourself that it won't be like this one day.
A decade or two later you realize you've become accustomed the darkness...
reply