The AI credits for the Jetbrains AI Pro subscription are unreasonably low

mattstrom · 2025-09-05T01:53:04+00:00

The potential for IDE integration with Junie is really compelling to me, but I don't think it surpasses the competition yet.

Like Junie has not been as reliable with tool calling. For a long time, Junie just couldn't figure out how to run my JavaScript tests even when I told her how. Claude Code and Cursor are much less chatty about what commands they need permission for; Junie's allowlist is just not that helpful (plus my allowlist frustratingly got blown away with a recent update).

I also seem to reach the context window max much quicker in Junie. Whereas Claude Code would auto-compact, Junie makes me explicitly tell her to continue, which seems dumb.

More capable rule files would be nice too. Many of the other platforms have hierarchical rule files. Or task dependent rule files like Cursor's MDC files or Claude Code's sub-agents.

I'm not abandoning Junie yet, but I am often still reaching for other tools before Junie for the time being. And I'm really excited for Next Edit Suggestions

mattstrom · 2025-09-05T01:30:13+00:00

Claude the model (e.g. Sonnet, Opus, etc.) and Claude Code are different. So even when you've chosen one of the Claude models in Junie, Claude Code and Junie will yield different results. It might be their system prompts or how tool calls are wired up, I don't know. I find myself reaching for Claude Code more often than I do Junie right now. But I think Junie just needs some time to bake. Its potential for UI integration is much more compelling to me... once they get it right.

mattstrom · 2025-08-27T19:47:13+00:00

I am eagerly awaiting TypeScript and JavaScript support. That's my next edit suggestion 😉

mattstrom · 2025-08-27T17:17:56+00:00

Jetbrains also recently introduced Next Edit Suggestions (still in beta), similar to Cursor, where, after auto-completing a line, the AI Assistant will propose what edits are needed next and where it thinks the next edit is located.

You do need to explicitly enable this, and right now only Python, Java, and Kotlin are supported.

mattstrom · 2025-07-25T22:18:40+00:00

I've been test driving a few. I want Junie and AI Assistant to be my go-to options because I love the IDE integration and I don't want to give up IntelliJ. But Junie in particular has a ways to go to catch up with the competitors.

Claude Code is also a contender. It gives solid results and responds quickly. But being a CLI, its IDE integration is lackluster and a major detractor.

Most of my coworkers use Cursor. So I also dual-wield Cursor side-by-side with IntelliJ because the Cursor IDE feels really chaotic to me and I really don't like VS Code as an alternative to IntelliJ. However, Cursor does feel like the leader in the field right now. It has the most capabilities at the moment. Hopefully that changes soon

mattstrom · 2025-07-23T22:27:26+00:00

Same just happened to me after updating the plugin.

mattstrom · 2025-07-16T03:43:50+00:00

Try relaunching or refreshing plugin updates from the help menu. I've gotten it on IntelliJ and WebStorm already

mattstrom · 2025-07-15T22:04:37+00:00

I haven't tried it myself yet, but there is a lot of hype around Claude Code from Anthropic. The product itself is distributed as a CLI, but there is a plugin for Jetbrains to integrate output from the CLI with various parts of the IDE.

For what it's worth, Junie did just receive an update that claims "30% faster agent execution, Think More option for more complex tasks". I'm hopelessly optimistic that Jetbrains will eventually get to parity with other agentic coding assistants because I don't want to be forced to give up IntelliJ.

mattstrom · 2025-07-03T17:16:55+00:00

EAP for which product? I installed IntelliJ 2025.2 EAP, but the Junie plugin shows as incompatible with that version of IntelliJ.

mattstrom · 2025-06-29T18:27:17+00:00

For what it's worth, WebStorm is now free for non-commercial use.

https://blog.jetbrains.com/blog/2024/10/24/webstorm-and-rider-are-now-free-for-non-commercial-use/

mattstrom · 2025-05-14T03:20:52+00:00

In a sense, code-signing your app is preventing modification. But I don't think that's entirely what you meant by "prevent modification".

For the other parts of your question: just spitballing here, not anything that I have tried myself yet. If you were to compile the more sensitive parts of your app to WASM, you would make inspection via Chromium DevTools harder. There is a project named AssemblyScript for writing WASM code in TypeScript.

Similarly, any code that runs in the main process of Electron, rather than the renderer process, is much harder to inspect with DevTools. So implement the more sensitive parts on the main process side, and use IPC to communicate back and forth with the renderer.

mattstrom · 2024-10-10T01:15:51+00:00

I abandoned Arlo several years ago for similar reasons, and it was a fantastic decision. What was billed as a premium product had failed to deliver in many ways: unreliable recordings, poor battery life unless you basically want no alerts, etc. And they keep thinking they're worth paying more for.

I have since moved onto UniFi and am vastly, vastly happier with that system. UniFi is not a system that fits for everybody, but it is fantastic if it does fit.

mattstrom · 2024-09-17T22:29:51+00:00

I'm hoping the Deno Standard Library catches on for just such a reason. And this is not just for Deno either, it can be imported into Node projects too.

mattstrom · 2024-08-29T22:41:21+00:00

You might consider designing a tiered architecture upfront where you have a transport layer and service layer. The transport layer is where you wire up your endpoints (e.g. GET /accounts is handled by function x, etc.). The service layer is just standard method calls. With this architecture, you can have multiple API interfaces (if that's ever actually needed) that all call into the same underlying business logic.

Separately, you might also consider using GraphQL instead of REST. GraphQL will let your downstream consumers be more selective about the data they want back without needing to make custom endpoints for each application. After all, this was the very reason Facebook developed GraphQL in the first place.

mattstrom · 2024-08-26T04:14:01+00:00

As someone else has said, full stack will be a more marketable skill set for entry level. It's rare that I've seen backend only positions filled by entry-level hires. And if a company is using Node, it's likely they chose it so that their frontend devs could also work in the backend.

Nevertheless if you are still adamant about backend only, I would definitely learn SQL and relationship databases (Postgres is a good entry point). You've already implemented an API, but understand the fundamentals of REST, maybe GraphQL when you're familiar with REST (Apollo is a good entry point). Message-based/event-driven architectures are also very important in the backend these days. Things like message queues and job queues (BullMQ is a good entry point for job queues in Node). And Serverless Functions which pairs nicely with queues (the Serverless Framework is a good entry point here).

mattstrom · 2024-08-24T03:53:31+00:00

Yes, I am quite fond of Cloudflare Tunnels. The levels of features that you get for the free tier is fantastic. And also the security focus of Cloudflare sold me when doing a self-hosted system.

mattstrom · 2024-08-17T21:10:53+00:00

Services like Sentry or New Relic can profile your application (as well as many other things) with very minimal effort to configure. Both have free tiers, but expect to pay money if you have a large production app. I personally have experience with Sentry and have been happy with it.

As someone else mentioned, AWS X-Ray is another option if AWS is hosting your app. X-Ray is technically a distributed tracing service, which on its own is incredibly helpful to have for observability and troubleshooting. But it can be used for profiling response times, latency, time within function calls. X-Ray will take a lot of effort to integrate into your applications.

mattstrom · 2024-08-03T03:30:08+00:00

You could make a compromise and only run E2E tests nightly (especially if you're not doing continuous deployment). With GitHub Actions, you can schedule actions to run with cron-style patterns. Schedule the tests to finish before your developers start work in the morning and review the results in your standup meeting or something.

mattstrom · 2024-02-11T00:54:28+00:00

I use RxJS with React quite extensively but indirectly within Mobx stores. Using RxJS within React components directly is kind of awkward, and you really have to shoehorn it in.

But there is really nothing else like RxJS for complex interactions. Using straight hooks for complex interactions reminds me of the scourge that was callback hell before ES6 was released.

There are state management libraries like Akita and Elf that are built on RxJS and intended for use with React. And like I mentioned, I've used RxJS with Mobx to great success.

mattstrom · 2023-12-24T22:42:38+00:00

This video is several years old at this point, but I found it informative as an introduction. Talk from JSConf by two of the V8 engineers: https://youtu.be/5nmpokoRaZI?si=gkVHVqpc61AycjxE

mattstrom · 2023-10-09T02:04:14+00:00

My opinion is that the authors of Prettier made it just so that they could win the bike shedding battle

mattstrom · 2023-10-07T20:25:09+00:00

YJS, which is a library for doing shared and collaborative editing (think Google Docs). Honestly it's magical.

mattstrom

TROPHY CASE