You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/Web/Blog/articles/2025-10-27-re-the-journey-thus-far.md
+46-7Lines changed: 46 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,12 +15,16 @@ Thank you! Appreciate it. What's especially good is that some of the design goal
15
15
16
16
Don't feel bad, it's nice to hear good things, but even better what can be improved!
17
17
18
+
## The Structure
19
+
18
20
> I know this doesn't sound very open-minded but the build-your-whatever mindset that exists with Tempest, I feel, presents the same problem that I currently have with React: if you don't know how to actually build software that can scale well, then you're going to build something painfully unmaintainable that you'll hate in a few months. […] Shipping with some expected structures, even if it's a templated setup option, feels as though it'd offer more guidance and denote a structure from the offset, with expectancy.
19
21
20
22
I actually agree with Vyygir. Starting from a completely empty src directory can feel disorienting. It's actually on our roadmap to have two or three scaffold projects, which you can choose from based on your preference. We haven't gotten to that stage yet because, honestly, we're still trying to figure it out ourselves. Maybe we should stop using that excuse and just build _something_. [Noted](https://github.com/tempestphp/tempest-framework/issues/1665).
21
23
22
24
That being said, I've experimented a lot, and I've refactored a lot. The one thing that sets Tempest apart from other frameworks is that it truly *does not care* about how your project is structured, and thus also doesn't care about refactorings. You can move everything around, and everything will keep working (given that you clear discovery caches in production). So even if you run into issues down the line, refactoring your project shouldn't be hard.
23
25
26
+
## Discovery
27
+
24
28
Moving on to Vyygir's thoughts about discovery:
25
29
26
30
> Let me start with this: I love the idea of Discovery. Composer takes us part-way there but Tempest's Discovery implementation absolutely nailed the execution.
@@ -35,13 +39,17 @@ However, there was one critique about discovery that I didn't fully understand:
35
39
36
40
> I had an idea that I'd use Discovery to find my entries in ./entries/*.md and then load them into a repository. I even tried it. But the major problem I was hitting was that my EntryRepository wasn't actually in the container at the point of discovery which, when you read through the bootstrap steps actually makes a lot of sense.
37
41
38
-
The way Vyygir describes it should indeed work, and I'm curious to learn why it didn't. It's actually how discovery works: it scans files (PHP files or any you'd like), and registers the result in some kind of dependency. Usually it's a singleton config, but it can be anything that available in the container. Vyygir actually mentions that he let go of the idea after seeing the [source code of my blog](https://github.com/brendt/stitcher.io/blob/main/app/Blog/BlogPostRepository.php#L75) (where I do a runtime filescan instead of leveraging discovery), but here I am thinking "why didn't I consider using Discovery for this???"
42
+
The way Vyygir describes it should indeed work, and I'm curious to learn why it didn't. It's actually how discovery works at its core: it scans files (PHP files or any you'd like) and registers the result in some kind of dependency. Usually it's a singleton config, but it can be anything that is available in the container.
43
+
44
+
As a sidenote: Vyygir mentions that he let go of the idea after seeing the [source code of my blog](https://github.com/brendt/stitcher.io/blob/main/app/Blog/BlogPostRepository.php#L75) (where I do a runtime filescan on one directory instead of leveraging discovery). A good rule of thumb is to rely on discovery when file locations are unknown: discovery will be scanning your whole project and relevant vendor sources, and your specific discovery classes that interact with that scanning cycle. If you already know which folder will contain all relevant files (a content directory with markdown files, for example), then you're better off just directly interacting with that folder instead of relying on discovery.
39
45
40
-
All of that to say: discovery should work for this use case (up to you whether you want to use it or not, but it should work). Maybe Vyygir was running into an underlying issue, maybe something else was at play. Anyway, Vyygir, if you're reading this let me know and I'm happy to help you debug.
46
+
Nevertheless, discovery should technically work for Vyygir's use case (up to you whether you want to use it or not). Maybe ha was running into an underlying issue, maybe something else was at play. Anyway, Vyygir, if you're reading this let me know, and I'm happy to help you debug.
47
+
48
+
## The Structure: Again but Different
41
49
42
50
> I had to make a last minute revision to the structure when I realised that DiscoveryLocation was not pleased with me trying to use a full cache strategy on views whilst having them outside of `src`.
43
51
44
-
Ok so, Vyygir wants his view files to live outside of `src`. While I personally disagree with this design (IMO view files are an equally important part of a project's "source" as anything else), I also don't mind people who want to do it differently. That's the whole point of Tempest's design: do it your way.
52
+
Ok so, Vyygir wants their view files to live outside of `src`. While I personally disagree with this approach (IMO view files are an equally important part of a project's "source" as anything else), I also don't mind people who want to do it differently. That's the whole point of Tempest's flexibility: do it your way.
45
53
46
54
Vyygir ran into an issue: view files weren't discovered outside of `src`. This is, again, something [we should document](https://github.com/tempestphp/tempest-framework/issues/1667).
47
55
@@ -58,21 +66,52 @@ The solution is actually pretty simple: Tempest will discover any PSR-4 valid na
58
66
59
67
Your view files themselves don't need a namespace, mind you; this namespace is only here to tell Tempest that `views/` is a directory it should scan. Of course, if you happened to add a class in the `Views` namespace (like, for example, a [custom view object](/2.x/essentials/views#using-dedicated-view-objects)), then be my guest!
60
68
69
+
## What's wrong with abstractions?
70
+
61
71
> I get the usage of interfaces in the degree they are. But my god, sometimes, finding a reference is painful.
62
72
>
63
73
> I feel like nearly everything is pointing to a generic upper layer that only vaguely implies what might exist when you're trying to understand how a segment of functionality works to, you know, implement something. And, because of how new Tempest is, not everything is fully documented yet. And the public use cases are slim pickings.
64
74
65
-
Ok so. I get it. The combination of interface + trait isn't the most ideal. I have a philosophy on why I prefer interfaces to abstract classes, and I've written and spoken about it many times before:
75
+
I get it. The combination of interface + trait isn't the most ideal, and you might be tempted to ask "why not use an abstract class instead?" I have a philosophy on why I prefer interfaces over abstract classes, and I've written and spoken about it many times before:
The tl;dr is that my view on inheritance is more inspired by modern languages like Rust, instead of following the "classic C++-style inheritance" we've become used to over the past decades.
81
+
The tl;dr is that my view on inheritance is inspired by modern languages like Rust and Go, instead of following the "classic C++-style inheritance" we've become used to over the past decades.
72
82
73
-
Within PHP, it's not ideal though. Specifically, because you need both the interface and trait, which introduces some complexity. That being said, I still believe that this approach is better than a classic inheritance tree, and I wish — oh how I wish — that PHP would solve it. Again, I've talked and written about this before, and even made a suggestion to internals:
83
+
PHP being PHP though, there are some drawbacks. More specifically that you need both the interface and trait, which introduces some complexity. That being said, I still believe that this approach is better than a classic inheritance tree, and I wish — oh how I wish — that PHP would solve it. Again, I've talked and written about this before, and even made a suggestion to internals:
Unfortunately, we haven't gotten a proper solution yet. My hope is that interface default methods will come back on the table, and the problem that Vyygir describes will be solved.
88
+
Unfortunately, we haven't gotten a proper solution yet. My hope is that interface default methods will come back on the table, and the problem that Vyygir describes will be solved.
89
+
90
+
I would really encourage you to read up on the topic though, because as soon as it clicks, I find I almost never want to rely on abstract classes again, and my code becomes a lot more simple.
91
+
92
+
## View Syntax
93
+
94
+
>I'm going to be honest, I just struggle to parse this mentally in comparison to something like Twig. This is almost definitely a problem unique to me (because my brain don't do the working right). I just wanted to mention it though.
95
+
96
+
That's fair. That's why we have [built-in support for Twig and Blade](/2.x/essentials/views#using-other-engines) as well. We're actively working on a PhpStorm plugin for Tempest View, which will make life easier.
97
+
98
+
## `DateTime` (no, not that one)
99
+
100
+
> Oh. Tempest's DateTime uses... a whole other formatting structure that I'm totally unfamiliar with. Sigh. Do I want to spend the time to figure this out?
101
+
102
+
Ok so, story time. We wanted a DateTime library that was more powerful than PHP's built-in datetime, so that you could more easily work with date time objects. Stuff like adding or subtracting days, an easier interface to create datetime objects, … (you can read about it [here](https://tempestphp.com/2.x/features/datetime)).
103
+
104
+
There were two options: [Carbon](https://carbon.nesbot.com/docs/) or the [PSL](https://github.com/azjezz/psl) implementation. We went with the second one (and added a wrapper for it within the framework).
105
+
106
+
IMO, we've made a mistake. Here's what I dislike about:
107
+
108
+
- We have `Tempest\DateTime\DateTime`, which has a naming collision with `\DateTime`. I cannot count the number of times where I accidentally imported the wrong library
109
+
- Having used Carbon for years, it's really annoying getting used to another API, eg: `plusDay()` instead of `addDay()`, etc.
110
+
- The date format. Oh how I dislike the date format. Just to clarify, PSL's implementation relies on [the standardized ICU spec](https://unicode-org.github.io/icu/userguide/format_parse/datetime/#formatting-dates-and-times), which in fact is more widely used than PHP's "built-in" datetime formatting. For example, with Tempest's implementation you write `$dateTime->format('yyyy-MM-dd HH:mm:ss')` instead of `$dateTime->format('Y-m-d H:i:s')`. You could argue that this just requires some "getting used to", but I, for one, haven't gotten used to it, so I can imagine how frustrating it is for newcomers.
111
+
112
+
That being said, we should also note that using Tempest's implementation is totally opt-in. You can choose to use either PHP's built-in `\DateTime`, or `Carbon` instead. However, how to do so is also undocumented. Again, [noted](https://github.com/tempestphp/tempest-framework/issues/1668).
113
+
114
+
## In conclusion
115
+
116
+
I'm so thankful for Vyygir taking the time to write down their thoughts. I'm also happy that most of their pain points come down to improving the docs, more than anything else; and this feedback will make Tempest better. Thank you!
0 commit comments