HackerTrans
トップ新着トレンドコメント過去質問紹介求人

adamscybot

no profile record

コメント

adamscybot
·7 か月前·議論
The point about CMSs having value in possibly being a more real-time collaborative UI layer to interact with that's less-scary for the average Joe is a valid driver; and is a critical factor for many use cases. But the the other stuff is clearly reasoning with a solution already in mind...

"All blog posts mentioning feature Y published after September...[more examples]...The three most recent case studies in the finance category...[etc]"

Fairly simple queries. If you're willing to build an MCP server (as they did for their solution), you could just as well build one that reads structured front matter.

"You can't. You'd need to parse frontmatter, understand your date format, resolve the category references, handle the sorting, limit the results. At which point you've built a query engine."

Well that's a scoped problem. Looks like it already exists (e.g., https://markdowndb.com/) and doesn't require moving away from Markdown files in GIT if you want.

Or use something like content collection in astro (https://docs.astro.build/en/guides/content-collections/). Hell, looks like that lets you have the MD files somewhere else instead of git if you please.

The AI-generated points aren't as compelling as the prompter thinks. A new common problem.

Yes, you don't need flatfile-committed raw text for AI tools to work properly, in part because of things like MCP servers. Yes, semantically linked content with proper metadata enables additional use cases.

The next point to make would be "if you use our thing, you don't need to think about this", but instead goes into a highly debatable rant about markdown in git not being able to fulfil those additional use cases on a practical level.

This distracts from the what I imagine is the real intent: "git and markdown files don't come automagically with a snazzy collaborative UI. And yes you can still use AI, and use it well out of the box. If someone tells you you need markdown in git to do x,y,z with AI they are wrong."

Personally, I can get over the "AI writing style", but only if the content still nails the salient point...
adamscybot
·2 年前·議論
One language that comes to mind is ReasonML. It doesn't have runtime checking. It's structural and compile time, but the guarantees are supposedly cast iron. https://reasonml-old.github.io/guide/language/type#design-de...

    type thing = 
      | String(string)
      | Bool(bool);

    let arr: list(thing) = [];

    let add = (item: thing, dst: list(thing)): list(thing) => {
      switch (item) {
      | String(s) => dst @ [String(s)] 
      | Bool(b) => dst @ [Bool(b)]    
      };
    };

    let newList = add(String("asd"), arr);

This doesn't work, since the dst array has to be one that can contain both string and bool in the first place.
adamscybot
·2 年前·議論
The "should we use node for the core business logic for my use case" thing is absolutely valid and depends.

But you'd be surprised about the "react for the front end of the CLI" part. I used this thing a whole six years ago in a complex interactive CLI and it came off great to use, maintainable and ergonomic. React is just one framework that proscribes to the "UI as declaritive/composable trees" pattern. And that UI doesn't have to be web based. That pattern works for all UI's I've come across.

Its the pattern that is a good reason to do this. And not react/js landscape. That part is probably a bonus for many though.
adamscybot
·2 年前·議論
Odd to see this come up. I used it about 6 years ago to produce a CLI for devs. It worked very well and React concepts map cleanly to pretty much any "UI" target as said targets can also be well represented by declarative & composable trees.

Probably, other Ui frameworks could also map, seeing as the declarative/composable tree pattern is ubiquitous now. So it's important to note it's that pattern which enables this, and not a specific framework.

But React is one of the ones that is also more removed from the web target than others.
adamscybot
·2 年前·議論
If you are used to structural typed systems though this actually "feels" expected. Don't get me wrong, I know where you are coming from. But the realisation comes from nominal systems, which are different beasts. As long as it actually evaluates to the expectations in the head of the developers using it, then that's okay.

However, regularly it's not the case -- especially with people moving from nominal systems.

TS can't really be practically nominal when it has to be constrained by its compile target. So I guess it ultimately boils down to an anomaly/criticism born from the legacy of how web standards came about.
adamscybot
·3 年前·議論
Interesting internal comms along these lines from 2013: https://www.techemails.com/p/imessage-for-android
adamscybot
·4 年前·議論
Right, huge +1 for Chakra. Chakra is basically tailwind but built on react primitives. It feels lot cleaner, and solves most of the issues mentioned.
adamscybot
·4 年前·議論
Its back
adamscybot
·4 年前·議論
In my experience its often the case the status site does not reflect reality -- until someone intervenes.
adamscybot
·4 年前·議論
I know about CSP and iFrames, but I think they aren't ergonomic enough to be used as mechanisms to restrict deps right?

Iframes need a full web context whilst CSP cant target individual code blocks. For example, I might want my code to be able to do alerts, but I dont want dependency x to be able to.

EDIT: Ah I think thats what you meant by your "code in a sandboxed iframe thing". Fair.
adamscybot
·4 年前·議論
TBH I think its not because JS somehow fundamentally attracts a different group of people, its probably more like:

- It being web based means you can target this kind of software for maximum "impact"

- NPM dep trees are massive and you generally have thousands of tiny libs. The chance of something like this happening and being noticed goes up therefore.

- NPM ecosystem is a bit more wild west which again leads to increased chance of something like this being able to occur in the first place.
adamscybot
·4 年前·議論
The web needs APIs that enables certain blocks of codes to run under specific permission constraints. Such constraints might include ability to read/write to DOM; window.alert; redirecting (well I guess CSP covers that one) etc. At least let us mitigate it.
adamscybot
·4 年前·議論
"Depends". The benefits of leaning on open source pays off the majority of the time. Are you exposed to more risk? Yes. Does that mean you shouldnt take that risk? Not really. Otherwise you'd struggle to move quickly and be competitive.

Of course certain things change this balance. Hopefully nuclear power plants dont have NPM in their toolchain. And I believe financial orgs already have quite heavy auditing of dependencies.
adamscybot
·4 年前·議論
Amazing! I always wanted Everything + deeper OS integration and this fits the bill.
adamscybot
·5 年前·議論
Perhaps give it another try, but with TypeScript. Im a front end dev and yes, I feel the JS pain. I look back at how I used to do things and think "wtf". TS completely changed this and brought it back to sanity.
adamscybot
·5 年前·議論
I think esbuild is basically already doing most of what Rome promises
adamscybot
·5 年前·議論
People are talking the other points to death but on the toolchain front, you might enjoy https://github.com/evanw/esbuild, which is rapidly gaining in popularity. Just 1 thing for bundling, transpilation etc. And its terrifically fast since its written in Go (ironic I know).
adamscybot
·5 年前·議論
What if you need that set of read/write operations to happen in one database transaction?
adamscybot
·5 年前·議論
One thing people havent mentioned as well is the importance of mutations. Querying is only one side of the story.

Your API should match semantic actions on your client like the UI and it needs to do this in such a way that it happens in one database transaction.

With REST, new UI requirement that needs to save 2 objects together across multiple entity types...? GG.
adamscybot
·5 年前·議論
Yep. OpenAPI spec is not rich enough to represent relations like this so its rubbish for FE dev to use to generate models/api client.

In general, the tooling/spec has thousands of open bugs, isnt going anywhere, moves very slowly and is missing fundamental features.

https://github.com/OAI/OpenAPI-Specification/issues/1998 heres the ticket where it will inevitably be ignored and die. But even if it was supported in the spec, the open source generators wont support it anyways.

Said generators also uses "logic less" templates to generate something that very much needs logic. As a FE dev, I love nothing more than to fork a an archaic Java based generator to get the client gen working...not.