The only place it make sense to me is the validation = at the route level you want to ensure that the given model exists / request attributes defining relationship (pivot), are there. This is how Laravel does this. Having said that this should be responsibity of domain rather than application
I might be missing something here, but I'm struggling to understand why the concept of mixing up implementation details by request path is desirable.
Maybe for colocating a legacy application with a new application that's slowly strangling it [0], but for a new application, this seems antithethical to using a framework in the first place. I can't say for sure why you liked Laravel, but I like Laravel/Rails/et.al. because I don't have to make decisions about the parts of the application that aren't unique to what I'm building.
This just allows you to yak shave on a route-by-route basis?
Hey. There are many use cases that involve mixing frontends. On the Primate website itself, the RSS feed is a route previously served by the Handlebars module (because it needed some logic), now by the (a bit more minimal) pure HTML module.
The rest of the website used to be written in Svelte, but the bundle got unnecessarily big. Because it uses Primate, I could rewrite the frontend part using Marko, shaving off around 30% of the client bundle size. Those are not things you can even try out if you're using one of the lock-in meta-frameworks. So a good framing of the counter question would be, why commit when you don't have to?
However, even if you never end up mixing two or more frontends: you have access to all other features using the frontend of your choice.
I think the next popular web framework would be something that would be optimized against llm code generation. So that the end result would be secure. correct. scalable(and scaling should be done by an llm).
> But web applications are not just pipelines of isolated tools. They are full of shared assumptions: request shapes, validation boundaries, session handling, rendering, routing, serialization, deployment targets.
Some of those things are specific to web applications. Others are not. It's fine for web-specific logic to be tied to all of the shared assumptions of a web framework, but application logic should not be. As the architecture evolves, the application logic may need to be run in other architectural contexts: as a message consumer, inside an orchestration framework, etc.
That's one of the most painful things about PHP. Entire businesses get built around business logic in PHP backends, and then when you need to execute that logic in a different architectural context, every line of it has to be rewritten, because it's too much work to extricate it from the context of serving web requests.
If you are designing your framework to contain application logic, then it should look ahead to the possibility of that logic being used in a different architectural context. It should facilitate and encourage writing application logic that is agnostic of the web context. Otherwise you're encouraging people to repeat the mistake of PHP all over again.
If you work in a legacy PHP codebase, it's inevitable that you'll see $_GET in the middle of what you thought could be isolated business logic. The coupling that was done in my experience old PHP codebases is awful.
I guess I can't blame PHP because it comes down to the devs to enforce decent boundaries, but I think PHP makes it easier than others to do so.
PHP is so much better now, but if you're writing PHP, there's a very good chance you're not working with that new, clean PHP.
Coming from Rails, which I’m sure informes part of the philosophy I really like this.
One design value of Rails is “Convention over configuration”, or what I sometimes explain as smart defaults over having to decide everything.
I see this is an area this project can help with; thought through folder and naming conventions; wrestling with issues at the seem between common tools. Making doing things the right way way (like database migrations) becomes the easiest way to do it; most of the time.
A bundle of smart conventions and ways of working that cuts down yak shaving and sometimes solves arguments as the project can be; well we thought on this a lot more than most of you and we’ve gone with this approach to stick these together and if you only half care now you can get this done for free for your apps.
This is like, the opposite of Rails and the "convention over configuration" style. It's making no decisions for you except to "use primate in the middle of whatever else you decide to configure!" Seems like it's actively encouraging making a mess of your stack. I don't understand it at all.
I remember at the beginning Google didn't want to share their SOTA datacenter with public, considering it a market advantage. So instead of raw VMs they decided to promote the "framework" model, where all the seams are polished, under the name of Google App Engine.
I remember we've been going through a security audit, and many of their questions were about ports security and server access -- well, we did not even have SSH access at all, and only 80/443 ports were accessible. It was a breeze.
However, as market has shown, people really do want finer control, SSH root access, and custom ports. Along with many more fine-tuning. For example, GAE autoscaler did not reassign a request that triggered a new instance, waiting for it to start for 20s even though all requests completed within 200ms, so other workers were available, but the request waited for its own instance to wake up.
So I'm skeptical of "seams hidden" approach, as over and over again I needed to tune that one hidden seam.
The English language has no words (yet) to capture that special combination of nausea and embarrassment one feels when they commit in good faith to reading a long piece of prose... only to slowly realize the whole thing is AI generated. But I'm feeling it more and more often these days.
Does that have something to do with OP's post, though? I mean, it's written like someone who's mostly formally familiar with English. Maybe your infamiliarity with formal English itself is factoring in, because the AIs are ALSO formal in diction?
I didn't get the same "AI wrote this" that you did, but I get a lot of people saying "AI wrote this" to stuff I definitely wrote by hand, all the way.
Genuinely curious, do you find HN to be AI-negative? (For whatever that mostly meaningless label is worth.) Would an "AI-positive / tech-positive" version of HN be just the same site, but with a smaller user base that holds similar opinions to you?
There's a wide spectrum of folks with different opinions on everything here, but I wouldn't say there's some lean towards LLM-hate. I'm not a fan of AI projects, but I can live with the (frankly) very high proportion of AI content co-habitating on this site.
For that reason, I don't think the root post here should be flagged really. That might get reversed, I think there's a flag-count threshold that triggers it automatically. But thinking HN is actively against AI projects stands in preeeetty stark contrast to the front page of HN! It's highly likely that people consider the concept of this metaframework to be bad, and they clicked the flag button instead of not interacting/leaving a curious comment, which is generally the way HN works.
Saying that, you should make one! Hacker mindset and all. It wouldn't be for me, but you might find a less confrontational atmosphere in your own space.
I think the comments on AI related projects are filled with negativity and uninformed opinions and I too find the atmosphere around here pretty off-putting lately.
I won't say that HN is some bastion of objectivity, but I do find people tend to be a little more direct on here. Individual comments can be pretty harsh as a result, but I tend to put at least some weight in the "HN hivemind" simply because I know there's a lot of people in important fields participating here. You absolutely don't have to agree with that, but I've rethought some things before because of that "negativity" that in hindsight; were indeed not great ideas.
If it feels that AI-generated projects are getting negative feedback, it might be worth interrogating why that is. It might not be because they're made with AI, it could be because they're not a great idea/not well implemented.
> find the atmosphere around here pretty off-putting lately.
Hehe. I chuckle because I've been reading comments like this one for more than 10 years now. You might be right. But if HackerNews is dying then it sure is taking its time.
> I don't think the root post here should be flagged really.
If you're referring to my post ...then of course I agree with you!
I should clarify that I am in no way whatsoever opposed to AI usage. I use it all day, every day like most of us here and, if we are doing labels now, then I guess I would consider myself generally AI-positive.
What I don't like is when people use AI to produce low-effort content, and then package it in such a way that it masquerades as high-effort content. Of course what is low-effort or what is high-effort are highly subjective. But publishing an article that has your name at the top, it's written in the 1st person, and yet it's very obviously 100% copy/pasted AI output -- this falls on the wrong side of ethical for me.
I suppose OP could put "AI-generated" or some such disclaimer on the article. But I would rather people just revise the output, actually engage with what they're creating before they dump it on the rest of us.
> Does that have something to do with OP's post, though?
Yes, the post reads to me as AI-generated, and then the author lightly revised the intro. They aren't evil for doing this. I just personally prefer reading things written by a human.
> I didn't get the same "AI wrote this",
The tells aren't always the same. For me LLMs have a certain indefatigable "bounciness" in their output that is impossible to miss. Everything has to be punchy. Everything shows the same level of (strangely elevated) excitement. At some point a human will do human things: put a little more detail here, vary their tone there, maybe lose the thread a bit and talk about something that's unrelated to the main flow. LLMs don't do any of those things–the writing is one speed from beginning to end. It's like riding a conveyor belt
> but I get a lot of people saying "AI wrote this" to stuff I definitely wrote by hand
I agree that there is a flip-side here where many people are eager to accuse AI usage for sometimes bizarre and facile reasons. And this is unfortunate, too. But it should illustrate the general frustration that many people are feeling about AI and its effects on social norms.
I think it lands differently for different kinds of prose (e.g. informational, persuasive, etc.)
Persuasive prose, in particular, which is probably the majority of the things that get posted here, is less persuasive to the extent to which it includes obvious "AI tells". Even in the cases where AI is more articulate, (1) the emotional weight of the text feels manipulative when it is clear that the emotions were, at best, "vetted" by a human as opposed to having been produced by one, and (2) I think we have a built-in "bullshit-proximity" sensor, and have recently been trained to expect AI to be more willing to engage in bullshit than humans due to their obsequious disposition. (For the record, I think humans are also full of bullshit, so this one's more of a toss-up.)
Great frameworks have great CLI tooling and just work. Be opinionated and consistent. The fact that this supports multiple frontends and multiple runtimes is a hard no for me, already know that it's going to be a massive headache to debug.
39 comments
[ 0.18 ms ] story [ 12.3 ms ] threadData is always the important part of any real program.
L(° O °L)
Maybe for colocating a legacy application with a new application that's slowly strangling it [0], but for a new application, this seems antithethical to using a framework in the first place. I can't say for sure why you liked Laravel, but I like Laravel/Rails/et.al. because I don't have to make decisions about the parts of the application that aren't unique to what I'm building.
This just allows you to yak shave on a route-by-route basis?
[0] https://en.wikipedia.org/wiki/Strangler_fig_pattern
The rest of the website used to be written in Svelte, but the bundle got unnecessarily big. Because it uses Primate, I could rewrite the frontend part using Marko, shaving off around 30% of the client bundle size. Those are not things you can even try out if you're using one of the lock-in meta-frameworks. So a good framing of the counter question would be, why commit when you don't have to?
However, even if you never end up mixing two or more frontends: you have access to all other features using the frontend of your choice.
https://jslightning.com
Sort of a PHP-like, folder based web serving tool that executes Javascript. Very quick and fluid.
Some of those things are specific to web applications. Others are not. It's fine for web-specific logic to be tied to all of the shared assumptions of a web framework, but application logic should not be. As the architecture evolves, the application logic may need to be run in other architectural contexts: as a message consumer, inside an orchestration framework, etc.
That's one of the most painful things about PHP. Entire businesses get built around business logic in PHP backends, and then when you need to execute that logic in a different architectural context, every line of it has to be rewritten, because it's too much work to extricate it from the context of serving web requests.
If you are designing your framework to contain application logic, then it should look ahead to the possibility of that logic being used in a different architectural context. It should facilitate and encourage writing application logic that is agnostic of the web context. Otherwise you're encouraging people to repeat the mistake of PHP all over again.
I guess I can't blame PHP because it comes down to the devs to enforce decent boundaries, but I think PHP makes it easier than others to do so.
PHP is so much better now, but if you're writing PHP, there's a very good chance you're not working with that new, clean PHP.
One design value of Rails is “Convention over configuration”, or what I sometimes explain as smart defaults over having to decide everything.
I see this is an area this project can help with; thought through folder and naming conventions; wrestling with issues at the seem between common tools. Making doing things the right way way (like database migrations) becomes the easiest way to do it; most of the time.
A bundle of smart conventions and ways of working that cuts down yak shaving and sometimes solves arguments as the project can be; well we thought on this a lot more than most of you and we’ve gone with this approach to stick these together and if you only half care now you can get this done for free for your apps.
I remember we've been going through a security audit, and many of their questions were about ports security and server access -- well, we did not even have SSH access at all, and only 80/443 ports were accessible. It was a breeze.
However, as market has shown, people really do want finer control, SSH root access, and custom ports. Along with many more fine-tuning. For example, GAE autoscaler did not reassign a request that triggered a new instance, waiting for it to start for 20s even though all requests completed within 200ms, so other workers were available, but the request waited for its own instance to wake up.
So I'm skeptical of "seams hidden" approach, as over and over again I needed to tune that one hidden seam.
As astro islands
I didn't get the same "AI wrote this" that you did, but I get a lot of people saying "AI wrote this" to stuff I definitely wrote by hand, all the way.
Everything gets labeled AI, flagged, and canned.
I'm getting annoyed at HN now and wish I could join an AI-positive / tech-positive version.
There's a wide spectrum of folks with different opinions on everything here, but I wouldn't say there's some lean towards LLM-hate. I'm not a fan of AI projects, but I can live with the (frankly) very high proportion of AI content co-habitating on this site.
For that reason, I don't think the root post here should be flagged really. That might get reversed, I think there's a flag-count threshold that triggers it automatically. But thinking HN is actively against AI projects stands in preeeetty stark contrast to the front page of HN! It's highly likely that people consider the concept of this metaframework to be bad, and they clicked the flag button instead of not interacting/leaving a curious comment, which is generally the way HN works.
Saying that, you should make one! Hacker mindset and all. It wouldn't be for me, but you might find a less confrontational atmosphere in your own space.
If it feels that AI-generated projects are getting negative feedback, it might be worth interrogating why that is. It might not be because they're made with AI, it could be because they're not a great idea/not well implemented.
Hehe. I chuckle because I've been reading comments like this one for more than 10 years now. You might be right. But if HackerNews is dying then it sure is taking its time.
If you're referring to my post ...then of course I agree with you!
I should clarify that I am in no way whatsoever opposed to AI usage. I use it all day, every day like most of us here and, if we are doing labels now, then I guess I would consider myself generally AI-positive.
What I don't like is when people use AI to produce low-effort content, and then package it in such a way that it masquerades as high-effort content. Of course what is low-effort or what is high-effort are highly subjective. But publishing an article that has your name at the top, it's written in the 1st person, and yet it's very obviously 100% copy/pasted AI output -- this falls on the wrong side of ethical for me.
I suppose OP could put "AI-generated" or some such disclaimer on the article. But I would rather people just revise the output, actually engage with what they're creating before they dump it on the rest of us.
Yes, the post reads to me as AI-generated, and then the author lightly revised the intro. They aren't evil for doing this. I just personally prefer reading things written by a human.
> I didn't get the same "AI wrote this",
The tells aren't always the same. For me LLMs have a certain indefatigable "bounciness" in their output that is impossible to miss. Everything has to be punchy. Everything shows the same level of (strangely elevated) excitement. At some point a human will do human things: put a little more detail here, vary their tone there, maybe lose the thread a bit and talk about something that's unrelated to the main flow. LLMs don't do any of those things–the writing is one speed from beginning to end. It's like riding a conveyor belt
> but I get a lot of people saying "AI wrote this" to stuff I definitely wrote by hand
I agree that there is a flip-side here where many people are eager to accuse AI usage for sometimes bizarre and facile reasons. And this is unfortunate, too. But it should illustrate the general frustration that many people are feeling about AI and its effects on social norms.
Persuasive prose, in particular, which is probably the majority of the things that get posted here, is less persuasive to the extent to which it includes obvious "AI tells". Even in the cases where AI is more articulate, (1) the emotional weight of the text feels manipulative when it is clear that the emotions were, at best, "vetted" by a human as opposed to having been produced by one, and (2) I think we have a built-in "bullshit-proximity" sensor, and have recently been trained to expect AI to be more willing to engage in bullshit than humans due to their obsequious disposition. (For the record, I think humans are also full of bullshit, so this one's more of a toss-up.)
SCNR :)