> You'd meet about what you were going to do, work on it, and come back a week or two later. Occasionally there would be informal check ins.
Planning meeting, ad hoc meeting doing the work then weekly/bi-weekly show and tells to show progress. Sounds like...some version of agile?
Remember agile and the XP movement that preceded it was invented by software makers, who had observed the pattern you describe and decided to be self-conscious about it.
Cool to see this out, but there is something about Tailwind I've never really got. And this is not from abstraction, but in production use on a number of pretty large sites.
Each Tailwind class corresponds to a CSS property, with a few exceptions where you have utility classes for degrees of that property (for example, padding, margin). Then along come these CSS component libraries, which substitute a thicket of these utility classes for a single class. Including Tailwind UI itself.
Given that the relationship of class to property is one to one, why not cut out the middle person and just use CSS directly? There seems no real advantage. You've basically indepedently re-invented CSS, while adding a strange layer of additional abstraction on top. It is nice and fast to write it in the HTML I'll grant, but, the speed advantage is not so great that it is worth it compared to the mental overhead of other aspects of working with Tailwind (e.g. having to trim all the classes with automated scripts and so on).
For each project, there's a unique balance between HTML, CSS, and the greater organization.
Consider a site that mostly renders Markdown or XML documents. Tailwind is probably the wrong choice. You have less control of the HTML content in this case, because it's generated. If you want to use Tailwind here, you'd need to make liberal use of Tailwind's @apply directive for basic declarations, which IMO is not the best expression of Tailwind usage. On the other hand, you have a lot of control over the CSS. It makes more sense to write the CSS directly.
Now consider an organization with many separate web properties, which all require consistent branding. The organization has a UI guy who creates universal stylesheets and components for use across sites. Here you have less control over the CSS, and more over the HTML. Tailwind makes more sense. You can add all the utility classes to HTML that you want, with few overrides or other enterprise pull-ups.
This latter scenario also highlights one of Tailwind's strengths. Tailwind limits your options. If you need to keep a brand consistent across a large number of properties, Tailwind keeps you in the guardrails of the style guide. I can't be the only one who's worked at an organization where there's supposed to be only one shade of blue to represent the brand, but you wind up finding 160 different shades of blue throughout the CSS.
Anyway, Tailwind has its time and place. I love it when it fits.
The source is open, and is available on GitHub, how is it not open source?
Why does software have to be free for corporates to exploit (AWS) to be open source?
For one thing, they themselves no longer call it open source, and restrictions on how software can be used violates central tenets of what open source is. You can read about this is copious detail at https://github.com/n8n-io/n8n/issues/40
Its because of the backlash here, i still remember being on the thread on launch. I still dont understand the sentiment,
People want things to be built and fixed for free, but in the end some corporate comes in and builds a saas on top of it (AWS again).
The code is open to read, free to use in a personal setting and company setting, you just can't commercialise it. Thats what Commons means, gatekeeping is the reason why, there is a prevalent confusion about GPL and open-source.
But being open source is not about the code being "open" to read, it’s about users being able to use it for any purpose, modify it if they want and share changes.
I'd argue that running something on a VPS is lot more a "forever service" than abusing Github's free tier for something that's not covered by their ToS.
I think the amount of time (work) you have put into this would have given you enough dollars to rent a smallish vps for longer than the life expectancy of GitHub.
$50/hour = assuming 10 hours total = $500
A droplet on DO costs $5/month. On few others, it's down to 3$/month.
That will run you about 8-10 years with yearly discounts.
Yes, you are right. Actually I have 3 vps of mine, but the workflows I want to do is so simple, just like rss -> telegram notice, and some filter, I don't intend to run a big process for this on vps. I believe some others have similar need too, so, I made this to help them save time.
Massive props to Studio 24 for showing their working in public on all of this. It is amazing to see. More large scale projects of this kind should do this sort of thing.
Its really thrilling to see someone think technical decisions out loud. So keep it up, despite what I am about to type!
There are a couple of interesting things in this article.
1. It is absolutely remarkable they got 15 days to rather requirements and choose a CMS. Having worked in a couple of agencies, this is a lot of time, which is to the good W3C paid for it.
2.
> We have very talented front-end developers, however, they are not React experts - nor should they need to be. I believe front-end should be built as standards-compliant HTML/CSS with JavaScript used to enrich functionality where necessary and appropriate.
It makes a lot of sense for websites to be written in HTML/CSS in this progressively enhanced way, but does it make sense for complex user interfaces like any WYSIWYG editor?
Even the Classic Editor basically dropped probably thousands of lines of (actually third party) Javascript into the mix in the form of TinyMCE.
3.
> We won’t stop trying though and plan to do more R&D with Gutenberg in the future. The W3C project, however, did not feel like the right place to do this. On a project as wide-ranging as this one, development time does become a factor.
This is about agency and project risk which is entirely fair enough. However, what is slightly strange, if risk of delivery due to unfamilar technology is a factor, is that the project then goes onto make two other decisions.
- Use Craft
- "We are currently considering a Headless CMS option for front-end page delivery"
It is unclear from this piece if they have much experience using Craft, but my project manager alarm bells are ringing a bit when a team is intending to "deliver project in technology they have no internal expertise in".
Of course, Craft is by all accounts excellent, but could be a source of problems. The judgement is between the technical difficulty of using Gutenberg and learning a whole new CMS as a developer.
Further: the headless CMS option.
Do the team have the experience of doing this? Where I currently work we are actually considering moving back from headless CMS because the current leader in the field, Gatsby, has some pretty major downsides.
One of the reasons is that site build time is terrifically slow. Their approach seems to be roll our own headless thing with Symfony which will presumably do calls in real time. Symfony is very full-featured, but this seems like rolling your own headless framework - who is going to maintain it?
Of course it could be very simple, but launching a project in: an unknown CMS, with an unknown way of doing a website, seems a strange move when one object seems to be reduce technical risk.
Most of this plain isn't true - afraid it does feel very much like a bubble there!
> - Uses PHP 5 spaghetti code with a handful of garbage event listeners and output buffering
I mean it has listeners for almost every event you might want to interupt and trigger something on that are well documented and have been for decades.
The PHP 5 code is very much legacy so I will grant you this.
> - Has no integration with composer at all
Composer support is absolutely fine and there are well maintained ways of keeping plugins and themes under Composer and have been for many years.
> - Doesn't have any form of content types without plugins
Yes, but adding further content types at the level of code or these plugins is easy, trivially so.
> - Has no cache, no theming engine, no multi-language, etc etc
It has several caches that are very powerful indeed, including those included by default. PHP is a theming engine.
Internationalisation built into the core, I'll grant the multi-language support is not as good as it might be. Could be better.
> - Beyond a media library it has literally no aspects of a "content management system"
I mean, people use it to run newspapers, so not sure if this is true. It depends what you need.
The organisations behind WordPress decided to meet their user need and provide a really good, well understood platform for content management with an extensively tested UX experience of end users. They prioritised this over developer niceities.
If the purpose of software is to augment human capacity and be genuinely useful, this was the right decision. The rough edges from a developer experience perspective have been largely smoothed off by a well established ecosystem like Roots.
> Composer support is absolutely fine and there are well maintained ways of keeping plugins and themes under Composer and have been for many years.
You need to use a third party service or setup.
> Yes, but adding further content types at the level of code or these plugins is easy, trivially so.
Compared to what? Drupal? CraftCMS? Joomla? Where you go to a UI and do it all, versus installing a plugin with it's own quirks or using functions.php which ends up being the last place you want to touch after your done?
> It has several caches that are very powerful indeed, including those included by default. PHP is a theming engine.
Fair enough. Probably at "agree to disagree" here.
I'll agree that its easier to do custom post types on other CMS. But sometimes at the cost of real overheads in terms of complexity for users to swallow to get there.
Caching is built into the core, which is what all caching plugins leverage, the interface to it is hidden.
PHP is a theming engine.
I've never got why people escape into Blade, Twig or so on. PHP was designed to have loops, logic, to take variables and so on and interpolate them within HTML. It has an alternative syntax to make this easier. It's one of the unique capabilities the language has over almost all other languages you'd use on the web. More often than not you end up escaping into pure PHP in any case in something like Blade.
> But the problem isn't random sites use WordPress, the problem is people build weird monstrosities on top of a really garbage system.
Don't think its garbage for the reasons explained, but I think this true of all software projects. Seen plennty of Drupal, Laravel or Joomla projects end in this state.
I've been learning Laravel and Statamic this year. Both are a joy to use. I've been building WP sites for about 7 years. My goal is to never build another WP site again. Gutenberg is just one reason why.
I think one thing that's missing from the templating engine argument is WordPress' data model. While PHP may be a templating language WP's API to access data is a huge pain. A great example is wp_nav_menu. To modify it in any meaningful way you have to use the Walker Class. Seriously? It's an array. If WP's data model were better you could definitely 'foreach' your way through that thing... but you can't.
Antlers has a shorthand syntax to cycle through its navigation type. Laravel doesn't have a native navigation type but when I set one up it's pointing to table of pages. At this point I can use Blade to go through that table and pull out the appropriate title and url.
Why is this nice? No more "#" for placeholder menu items. More control over the Aria roles, etc.
This is just one win, in my experience, of using Laravel/Statamic.
Massive fan of Laravel. If the relationship between Statamic and Laravel is similar to that between Wagtail and Python, plus the static storage, it seems like it would be very good indeed.
I don't know anything about Wagtail or Python so I can't speak to the comparison. However, I chose Statamic because it's a Laravel package and can be extended via Laravel. That adds a lot of flexibility to it. From what I understand Livewire is also compatible with Statamic.
> I've never got why people escape into Blade, Twig or so on. PHP was designed to have loops, logic, to take variables and so on and interpolate them within HTML.
Compare a Twig theme with a PHP based one. The former is much cleaner because views and controllers are separated, there's clean ways to reuse views, and the syntax is cleaner and more concise for common operations. The standard PHP approach in WordPress gets messy really quickly.
Related, but I can't believe how much responsibility WordPress theme writers have to manually make sure echoed strings are escaped properly (Twig has the same problem because it would be fighting against WordPress otherwise).
Mate, Wordpress does not even have a way to manage your images without using a plugin. People using Wordpress to run newspapers and magazine sites have to use a hacked together solution involving either more plugins or writing custom code. As someone who's had to run a magazine site with Wordpress, I can painfully recall all the issues I've faced and cursed the dev team.
When you have a few hundred images (and that's just for a small site, let alone newspapers), do you really think having just a dropdown with media type and month for a filter (out of the box) suffices? Asset management is a core feature for any large-scale media outlet CMS.
> PHP was designed to have loops, logic, to take variables and so on and interpolate them within HTML. [...] one of the unique capabilities the language has
Totally agree, but unfortunately PHP's integration within a markup processor is quick and dirty, without consideration for context-dependent escaping and quoting etc. hence continues to give rise to a large number of HTML injection attacks.
This is true. I understand other languages (for example Go) have very nice features of this kind - contextual auto-escaping and so on. However a lot of other languages also have these footguns around escaping and security.
It's a perennial but: unit tests are more about how you think and rigourously approach a problem than preventing regression. I'd say if you wrote unit tests and then deleted them, your code would be better for it. Indeed, I often don't commit some of the tests I've written in order to write the code! I'll ship some subset of them. It's a notebook.
They serve as a form of living documentation for the code and help increase velocity in a build under the right conditions.
For example, you do need to know a certain function does what you think it does because the rest of the system isn't even in place yet. You might have to approach this from the outside, via integration, but the speed of doing this is quite slow. Versus a unit test.
This is not to mention refactoring!
The piece seems to be more about the value of mocking and how far to go with isolation. Which is a slightly tangential issue. I agree that in particular styles of object orientated programming this becomes absurd.
This article, which is linked provides a more convincing case, on the grounds that unit testing foregrounds the system as software as opposed to the software as a useful and functional thing in the world, meeting user needs.
However, it omits the being about to _react_ to user needs is actually a central party of agility. Unit testing allows maximum reactivity to changing requirements without regressions in the code and makes this code navigable. Changing customer needs means your carefully built functional tests are going to be just as useless and rotted. This has been the case with large test suites of functional tests - say in something like Cucumber - I've seen. Better test at a lower level, which moves slightly less rapidly.
While this is a great talk, and a great web app, I think there is a bit of over compensation on their part, because of them being in the unique position of having founded and had to manage the ticket burden of a very popular (backend) framework - Django.
It's odd because in the talk he advocates patterns over frameworks. Django is an implementation of MVC, as is well known. What is the value of implementing MVC again in Python when someone really has done that job for you?
There is a bit of a slight of hand here. If someone had built a frontend framework in Javascript and was now no longer advocating them, that would be a cleaner argument. But we have a shift of abstraction here from front to back end, when the two domains need to deal with different worries.
Backend or frontend, I don't think it makes a difference for the points of this talk: build your own codebase, use what you need as you need it, consider following established patterns if you find ones that fit your problem.
Django is used as an example of the downsides of a framework, and how the complexity of frameworks explode even though any given user only needs a small percentage of the features.
"The value of a software is not the code itself but in the reasons behind the existence of that code"
I wholly agree with this. However, I'm sort of baffled by this approach. What frameworks allow is you not to have to continiously solve the same problem and waste weeks implementing something that others have solved.
For example, I worked with a team that spent weeks on "given a certain event happens in the software, dispatch a notification to the user". In the world of Rails, Django, Laravel and Phoenix this is a configuration task, with existing libraries. In Javascript it was a slog getting the implementation that still lacked much of the functionality of these mature frameworks (there are notification frameworks for Javascript but it was decided not to use them - "no frameworks"!). While it is fun to implement your own thing, here the reasons behind the existence of the code are essentially developer vanity in thinking their notification situation is an absolutely special case, and developer desire to do something stimulating like develop a notification system rather than serve product, organisational or user needs.
To have a clear discussion of this, however, it might be useful to define "framework". Is the target here frontend or backend frameworks? One thing I have observed is in the frontend world frameworks have caused some core skills to atrophy. For example, how many Javascript front end engineers can now confidently, given you click on something, change the colour of it. Probably here a framework is wildly overkill and you will get there with plain Javascript until such a point as complex user interaction is needed.
Realise rhetorically there is less punch to "use a framework mindfully" but this should be basic to any engineering decision "use a language mindfully" and in the last instance "do we need to solve this with software"? Doesn't sound like a movement per sae but corre software engineering skills - use the right tool situationally.
You seem to be equating frameworkless with library-less.
> a team that spent weeks on "given a certain event happens in the software, dispatch a notification to the user".
This is trivial without a framework as long as there is a library you can use to "notify the user" (e.g. an email or chat library). It's actually easier without a framework because "event" is just a line of code somewhere in your own application, while in a framework, it can mean a million things and maybe NOT what you actually wanted.
But libraries are much more effective in frameworks.
Say an event that shows a message to a user next time the user sees a page has to know about users, has to be able to store messages for users and remove them once they have been shown, it needs to know about i18n, and have tools to display the current messages in HTML.
A Django library for it can assume the existence of Django for all those things, a general library has a much harder time.
No, I'm not. Libraries were certainly used in this case.
But whereas in Rails this would be mixing in a library to a controller to allow events and configuring them, this was building a new set of models and code over the top of a library for something like Mailgun from no code. A two hour job in Rails/Django/Phoenix but a two week sprint long job to roll your own. Why bother?
> how many JavaScript front end engineers can now confidently, given you click, change the colour of it
The overwhelming majority of JS developers learn the basics before moving on to a modern framework. The most common exception I've seen is backend developers picking up front-end tasks.
If all you're doing is changing the color of something, obviously you don't need a framework. In other breaking news, you don't need a chainsaw to slice bread.
> The overwhelming majority of JS developers learn the basics before moving on to a modern framework.
I'm not sure if this is the case.
I actually set this as an interview question for mid-weight to senior on paper front end engineers and a solid 60% couldn't do it - this was four years ago. Not being able to do this wasn't a "fail" by the way, it was more something to talk around, especially when people successfully reasoned it out without knowing the underlying API, but it did reveal a relatively shallow understanding of the browser environment.
I imagine it is significantly worse now. Do the training course at boot camps take people up from `querySelectorAll` before jumping into React? I'm not sure they do.
Planning meeting, ad hoc meeting doing the work then weekly/bi-weekly show and tells to show progress. Sounds like...some version of agile?
Remember agile and the XP movement that preceded it was invented by software makers, who had observed the pattern you describe and decided to be self-conscious about it.