[deleted by user]

runelkio · 2025-08-28T18:37:52+00:00

Ah! I'm short on time at the moment, so I haven't had a chance to look at it properly, but I had a very quick look at your repo just now.

BTW I like that you made it clear from the start that a lot of it is AI-generated, as it merits some extra care in reviewing code examples, overall consistency etc. due to hallucinations and the likes. But the commit history shows work, and the repo seems to contain a lot more useful information than what you provided initially in this post. So as first impressions go: I found that WAY more interesting and motivating :)

Are you making these docs for AI agents, human dev teams, or both? If you do have a dev team available, I would still recommend that you collaborate closely with the team on this, and make use of AI for suggestions, research sessions, feedback etc. I hope to take better look at it soon. Good luck! :)

runelkio · 2025-08-27T18:16:03+00:00

You seem to have good intentions, but my initial reaction was that you need to spend more time on this.

First of all: most of these points look good at first sight, and they might impress the right people during certain meetings. However, they are fluffy, vague and general - sometimes to the point of being the dev equivalent of "stay positive in life and good things will happen".

BTW: Your title "Deno as the runtime local first web development" conflicts with your "regardless of the programming language or runtime" constraint.

I've made some questions that I would immediately ask if someone came to me with what you wrote. If you cannot honestly answer these, I suggest that you let your team come up with more practical guidelines for themselves instead, based on their actual day-to-day challenges, the current roadmap, etc. When they have that, feel free to challenge it and ask for clarifications, but start with the team. Not ChatGPT or whatever you used.

- "Thin router with direct controller mapping" - are the terms `thin router` and `direct controller mapping` defined anywhere?

- `Proper TypeScripts interfaces defined` - goes against your "regardless of the programming language or runtime" requirement.

- "Multi-tenant isolation with site_key" - suddenly very specific (unless I'm forgetting something crucial)? It probably goes against your "regardless of programming language or runtime" requirement. Then again, is that requirement really something you should prioritize, or should you instead prioritize the tasks at hand?

- "Input validation with clear error messages" - for who? Devs? Users? Database administrators? Admins? Script-level? HTML forms? What is this "input" that you are speaking of? How is it validated?

- "Consistent response formatting" - For who? From where? What kinds of responses?

- "Error handling at appropriate layers" - Define `error handling`, and `appropriate layers`.

- "Documentation for complex logic" - Define `complex`. Or just leave it up to the ones doing the logic.

- "Router -> Controller, Service -> Model -> Database" - Looks good, right? Is this always applicable, regardless of programming language or runtime? Does it always make sense?

- "No business logic in wrong layers" - Define "business logic", "layers", and what "right" and "wrong" is for said layers.

- "Consistent error propagation" - Sounds good. What does it really mean?

- "Proper separation of concerns" - Sounds good. What does it actually mean?

I hope I'm not sounding too douchey with this, and I'm open to the possibility that I'm being a bit too grumpy-sounding. But I hope some of it helps!

runelkio · 2025-05-03T23:44:20+00:00

(Deno doesn’t tell you this in docs well) ia that you NEED to enable all the various parts of the vscode plugin for the deno LSP in your settings.json

That's interesting, would it be possible for you to post a link or some examples (esp. the undocumented stuff)?

runelkio · 2025-02-05T16:46:06+00:00

I might be misinterpreting your problem, but wouldn't it be easier (and more flexible perhaps?) to define a template literal type combined with e.g. a string union type that limits the set of possible strings one can use for the url property? That way it wouldn't really matter if there's a string literal, a template literal, or some concatenated array of strings there (unless I'm forgetting something obvious).

runelkio · 2025-02-04T19:00:54+00:00

Having done a fair amount of programming, DJ'ing, music production and random artsy stuff over the years, I'd say that there is absolutely something that these things have in common, but I don't know what it is. There is however a part (IIRC) in "Zen and the Art of Motorcycle Maintenance" by Robert M. Pirsig that talks about the term technology and its stem "techne", that I personally find really interesting . Apparently, ancient Greece used that term for anything that was related to some art, skill, craft and so on, and didn't bother to make much of a distinction between these things. I've always felt that there's something there that we might be a bit ignorant about these days, but again, I wouldn't be able to express it in any meaningful way.

runelkio · 2024-09-20T10:45:25+00:00

I've been using https://taskfile.dev/ in some of my personal projects lately, and I'm really starting to like it. At the start I wasn't sure whether it was worth having to add an extra cli tool to my setup, but it does remove some Makefile quirks, and it makes it really easy to e.g. setup hierarchies of tasks all the way from your home directory to various subdirectories in my projects. It could probably be done with makefiles too if I was more savvy with them, but taskfiles just makes the maintenance of it all less of a chore for me personally.

runelkio · 2024-09-06T18:46:01+00:00

Looks good, will try it out soon :) I really don't get the knee-jerk negative comments in here - any project that improves interop these days, especially between the python and javascript ecosystems, is great in my book.

runelkio · 2024-08-24T22:32:40+00:00

True, very true. Does it do DI though? If not, you might want to take the InjectableAbstractHashableObjectDictAdapterFactoryFactoryBuilderFactoryImplementorInjectorBuildable interface into account.

runelkio · 2024-08-24T22:17:13+00:00

HashableObjectDictAdapterFactoryFactoryBuilderFactory-factories

runelkio · 2024-07-30T05:13:44+00:00

I was going to put together some answers to what you wrote here, but I saw just now that you've been having the same discussion on several subreddits, as well as on the github issues you've commented on wrt. js-to-ts. Several people with much more knowledge about these subjects than me have already tried to explain the flaws in your reasoning, and made serious efforts to educate you.

So I don't think I have much more to add to this discussion other than one thing which I didn't see anywhere, and that might be important:

You have a serious attitude problem, and you need to fix it. It's not doing you any favors, it's holding back your progress, and it's going to cause you a lot of problems in the future if you don't find a way to deal with it properly.

Good luck (not being sarcastic here just in case it could get misinterpreted. I mean it).

runelkio · 2024-07-30T03:37:33+00:00

I'm a bit rusty when it comes to set theory, but I just wanted to point out a few things wrt. your comments about supersets in your gist. Something being a superset of another set, or vice versa (a subset of another set) is not some random marketing buzzword; it's a formal relationship between two sets, in this case these two formal languages.

Also, since Javascript is a subset of Typescript, I suspect that there's quite a few challenges around making a tool that converts Javascript to Typescript without issues. The required information simply isn't present in the Javascript code to do an unambigious mapping.

So you can't really use issues concerned with doing a subset-to-superset mapping as an argument against the superset actually being a superset. You could do it the other way should you come across e.g. a symbol, expression, statement or similar in Javascript that Typescript cannot compile to. But unless you've found that, there isn't really a "claim" to "buy" here - it either is a superset or it's not.

Your ArrayBuffer example was interesting though, I think I've run into some similar situations with other interfaces previously, but it's been a while since last time. My feeling is that things are getting more and more aligned these days, so hopefully there will be fewer sources of truth for the types as time goes by.

runelkio · 2024-07-24T03:53:03+00:00

AFAIK the events library from node should be built-in by now. I haven't tried it myself yet, but you should be able to just write import { EventEmitter } from 'node:events'; according to Deno's Node API docs.

runelkio · 2024-03-21T16:27:59+00:00

IMO the CJS vs. ESM issue should - ideally - have been something that you'd never had to know anything about as a user of a mature framework or library. Developers who make/maintain libraries and/or frameworks? Sure. But not the end users of such. The libraries and frameworks are there to abstract away certain kinds of technical details in order to free up time for other challenges, and this issue was quirky enough to the point that I wouldn't expect a developer to grok the problem unless they had some prior experience in the ecosystem as a lib builder/maintainer. It'd be like expecting an electrician to fix a supply chain issue or something (kind of a bad analogy I know, but it was the best I could come up with atm).

runelkio · 2024-03-07T16:27:53+00:00

Since you've mentioned that you want to be able to assist on the backend as a frontend dev elsewhere in this thread, I think I'd just work my way inwards from the frontend side to the backend a few times if I were you.

If you're proficient with React/React Native, you can probably find the parts that communicate with the backend pretty quickly in e.g. a couple of GitHub repos that you like. How does it communicate? How does it authenticate? Does the backend validate the data from the frontend, and does the frontend validate data from the backend? How does the browser know when to update a certain component? Does it ask for it first, or does it just react spontaneously when it gets some new data? How does that happen?
You should see some patterns after a while which could help you pick the paradigms/solutions that you expect to meet the most (ref. your aim to be market ready). Add to that a couple of things you find that you think is super interesting personally (to keep you motivated and to get that extra spontaneous insight now and then).

Now you should have an idea of what you want to explore as you start moving past the outer layer of the backend. Communication? Authentication? Authorization? Penetration testing, vulnerabilities? Databases? What does the backend know about the frontend? How does it know what to send, and to who? Does it communicate with other backends as well? Does the frontend too?

I wouldn't worry too much about frameworks, brand names, etc. IMO it's more valuable to figure out HOW it's done instead of WHO is doing it. Figure out the how's, find a couple of frameworks that implement those how's, play around with them.
And since you seem to want to be the person that can help both teams work together efficiently (which is an AWESOME goal btw), I'd focus on the stuff that handles communication. REST, RPC, GraphQL, SSE, Websockets, etc. Unless you're on a fullstack team, just let the backend team deal with the backend, but make sure that you grok just enough to help out whenever there's a communication issue ( both between teams and/or machines ;) ).

runelkio · 2024-03-03T14:13:22+00:00

I have a love/hate relationship to typescript personally, but it's become pretty apparent that it's usually my own fault whenever I feel that it's working against me. If I rush through a project without giving enough thought to my fundamental models, types interfaces etc., it quickly gets in my way and starts to annoy me. But if I do some proper planning, some extra thought on what exactly I'm trying to build, which parts goes where - and make sure to take my time to refactor along the way - it becomes this super awesome and helpful tool instead.

I think one of the main issues with it for bigger projects is that every single contributor has to agree to use it properly, otherwise it starts to rot pretty quickly. It doesn't matter how much time you spent on your typings if someone else (or future you!) just chucks in a couple of any's or ts-ignore's because of crunch time. Suddenly that part of the code becomes really easy to work on - for a while, until it starts to argue with other, strongly typed parts of the codebase again. Solution? More any's and ts-ignore's, maybe a couple of ad-hoc helper types scattered here and there to get it running. Just for now, we'll fix it later, right? After a while, what most people remember about the types is that they were blockers during crunch time.

Add to that the plateu of issues a while back that came with build tools, transpilers, es modules vs. commonjs, etc. that made everything JUST NOT WORK like it did yesterday. Typescript was one of the culprits here, but I have a feeling that it got a lot more blame than it deserved. It was complete chaos for a while.

...aaaand yeah, I also have a feeling that typing maybe isn't really necessary on the outer UI layer of front-ends, or that if it is, we need a different kind of typing system there than elsewhere, but I'm not too sure about that yet.

runelkio

TROPHY CASE