DEV Community: Simon Hamp

Why You (Probably) Shouldn't Start With an SPA

Simon Hamp — Thu, 01 Feb 2024 00:00:00 +0000

Some history, some context
When does an SPA make sense?
So, why are SPAs bad again?
- Your front-end and back-end get decoupled!
- It may hurt customisability
- Performance will suffer
So what's the alternative?

I came across this interesting article by @gregnavis the other day. I guess it's from a few years ago now, judging by some of the other posts on his blog. But it still holds up. It's maybe even more relevant now.

The article is entitled The Architecture No One Needs and it makes a simple and clear case, arguing that SPA's are more expensive than a standard multi-page app (which may or may not be a monolith).

I'm going to use SPA throughout this post to mean the whole umbrella of ways you might be building a front-end application that is not server-side rendered.

I think this is in line with Greg's intent too.

I don't want to split hairs over whether a particular framework can be used to build front-end apps that aren't strictly SPAs.

Since I read it, I haven't stopped thinking about this article.

I found myself agreeing with all of Greg's stated points and it made me realise I actually have a strong opinion about this topic.

I believe Greg is right, and as time rolls on I think I'm becoming more bullish in my stance on SPAs too.

¶Some history, some context

My foray into the dirty, hubbub streets of front-end frameworks came about because of Laravel Nova and Statamic. They both use Vue, so I learned Vue.

Of course, I looked around. But React made me wretch. Angular almost made me want to buy a katana just to perform seppuku.

I hear things about all of these and more thanks to Twitter. I can say some of it is good, but most of it continues to push me away.

I stuck with Vue. I actually like Vue a lot, even if v3 has caused a bit of headache—it's actually better for it in my opinion and yes I do like the composition API.

Overall though, I'm definitely heading more towards preferring not to have to build my front-end using node/deno/bun or whatever tool becomes popular today.

That said, you just try and pry Tailwind from my frigid, rigid fingers!

I'm quite firmly in the Livewire camp now. In another life, I may even like HTMX?

I've built a few SPAs, but I can probably count them on one hand. But not only will I probably not build another one, I think you shouldn't either. I'm strongly encouraging my clients not to.

I do think SPAs have a place, but it is almost certainly not in your project.

Yes, I know this argument has been made before and probably far more eloquently than I'm going to, but you know I just felt like I needed to get this out of my head in my own way.

¶When does an SPA make sense?

Let's get this out of the way first before I dunk on SPAs some more.

They do have a place:

I believe that the main advantage of an SPA is/was/has always been the decoupling of the front-end from the back-end.

As time goes on and engineers specialise in areas that interest them the most, roles become more well-defined. This is why we have 'front-end' and 'back-end' and 'full stack' engineers.

Although there is principally a lot of overlap (this is all programming at the end of the day and many concepts are similar), the domain—the environment that the engineer is most familiar with—is what determines their preference.

Some engineers will prefer back-end because they don't want to think about or deal with a certain class of bugs or issues that arise from the rapidly-evolving world of front-end development.

They may be uncomfortable using 3 or 4 different languages at the same time to get their work done, or they groan as soon as there's another major version of some framework which is going to require a load of refactoring that doesn't add immediate value to your product.

Consider: every user of your app could be using a different version of a particular browser, which uses one kind of rendering engine, and a specific level of conformity to various web standards e.g. ECMAScript (the official standard that underpins what most of us think of as JavaScript) or CSS. Keeping on top of these variations and differences across desktop and mobile is enough to make anyone's head spin.

And other engineers will prefer the front-end for its stateful nature, or because they're more comfortable with JavaScript/TypeScript, they grok CSS, and they love the intersection of code and design.

Or maybe they just dislike dealing with databases, concurrency, queues, messaging and APIs a lot more than they dislike wild browser evolution.

In any case, whatever size your team is, there will be these preferences. For example, I consider myself a full-stack developer, but honestly I like to avoid front-end work as much as possible, so will generally take the easy route there.

Developing an SPA could allow you/your business to split the work of front-end and back-end into separate teams, which may help each team focus so they can do what they do best and be the happiest they can be.

Which is the most important metric that will make an appreciable difference to your bottom-line long term.

Being intentional about this will see you hit Conway's Law head-on and potentially tackle that beast in the best way, as long as you build up the necessary lines of communication.

It also allows you to scale the two parts of the system separately—both in terms of team scaling and resource scaling—which, if you ever need that flexibility, could end up saving you from a certain group of headaches.

And I'm gonna be honest, building distributed systems like this is a cool problem to solve and will be a point of growth for many of your engineers.

¶So, why are SPAs bad again?

Yeh, so far this all sounds great, right? Well, just letting ol' Conway right into your living room isn't exactly the best idea.

Aside of all the points that Greg makes in his article (if you haven't read it yet, go read it), I want to present three extra reasons why I think an SPA is a bad idea.

¶Your front-end and back-end get decoupled!

Your back-end and front-end are always coupled. So trying to split them in anything but the most extreme circumstances is an exercise in futility.

I think this is probably the worst part of this whole story.

If your back-end team want to move in one direction, they've got to align with the front-end team. If timings and priorities don't work out, it's going to force someone to either put a hold on some work that really needs sorting out or do some grunt work just to patch over a hole that's about to appear.

This is communication overhead. It adds risk. It adds complexity. It adds meetings into engineers' calendars. It adds friction, and stress, and distraction.

It flies in the face of that number one principle: let your teams focus and be happy.

This literally costs you money one way or another, cost that you could avoid.

Deployments get unavoidably riskier in ways that are super difficult to test because testing distributed systems is really hard.

Again, this might all be fine, in the most extreme cases, where you need the decoupling. Then this extra expense, and complexity, and churn-causing evil, is just a necessary evil that you have to learn to swallow and live with.

But I've got x engineers, y1 are front-end, y2 are back-end. What do I do?

I would strongly recommend that one of your engineering groups need to roll up their sleeves and get on learning the other group's code, tooling and responsibilities.

This will have multiple benefits: career progression and learning opportunities, increased bus factor, fewer meetings and more collaboration.

Sure there will be challenges too, but they won't be as big or as painful as the other challenges you'd face with an SPA.

¶It may hurt customisability

As I mentioned earlier, the reason I got into Vue at all was because other tech I was using required me to. In both Statamic and Laravel Nova, the choice of Vue—well, not specifically Vue, but rather a reactive front-end framework—made sense because at the time it really was the best way to build flexible, reactive front-ends.

And both of those tools needed that power and have become fantastic tools because of it.

But there is one pain point that it's created that's quite hard to escape: the customisation story for each of these is harder because of it.

How so?

Basically, because each tool needs to build the assets to ship their product. And once they're built it's hard for third-parties to build on what's already there.

How is it harder? Let's say I'm creating a Statamic add-on that allows CMS owners to post to social media from their control panel. As Statamic uses Vue and already has a bunch of components I can leverage, I am going to use some of them.

But I'm also going to add some of my own functionality that doesn't already exist within Statamic. Now what happens? Well I build the Javascript... but wait. I can't change the bundled JS that's part of Statamic core.

I have to build my own JS and load it at the right time, something I'm not in control of. Thankfully the Statamic team (building on tooling from the Vue & JS community) have worked hard to make this relatively easy, but my tool choice is now limited by what they support - if they're using Vue 2, I have to use Vue 2; if I don't like Vite or Webpack, tough luck.

And on top of that, the builds have to happen at the client's end, which means we're now offloading some of the responsibility of making this whole thing work to people who don't need or want to know anything about this stuff. They just want to install your thing and get on with their jobs and lives.

Why is this such a pain though? It used to be (in other platforms) that I could just load some extra JS file into the admin interface and do what I want.

Honestly, we probably should never have been doing that either. Hands up, how many of you have seen a WordPress installation that tries to load 2 or more different versions of jQuery? 🙋🏼‍♂️

So these build tools go some way to alleviating some problems, but in the process have introduced so many layers of protection and abstraction that it presents a brain-melting, Japanese puzzle box to unlock.

And all this JavaScript flying around is really unsafe, because JavaScript is completely malleable on the client side.

That's meant library creators have had to go to some unusual lengths to protect the state of the application and encapsulate the code in attempts to make it safer and more portable.

I won't pretend to understand all of the requirements, pre-requisites and implications for why built JavaScript assets are packaged up in a complex soup of function calls and obfuscated code, but suffice to say this makes building on top of pre-existing code that much harder.

The web standards track is working to make this easier: we have Web Components and module starting to come through which should alleviate some of this.

But if you're not building with those standard in play—I understand, it might not be possible because of browser support etc—and you want to expose your user's to third-party plugins/add-ons, then you've got to figure out how to make it easy for other developers.

Some of that's going to require the specific implementation, the other part is going to be documentation. No matter how you cut it, it's going to be harder to get right than if you had server-side rendered views that you allow your third-party developers to load at runtime.

¶Performance will suffer

This isn't really an extra reason as Greg did touch on this a little already, but I wanted to go harder on performance.

You should never choose to build an SPA because of some supposed performance benefit.

That is the wrong hill to try and defend for many reasons, but primarily because you've got the whole of the web stack—on horses, with bazookas—nipping at your heels.

Sure, it may take a little while for web standards to get ratified and then rolled out, but the reality is that it's only a matter of time.

We now have wide browser support for QUIC / HTTP/3 (which brings faster downloads and reduced server load) and things like 103 Early Hints response headers (which let us tell browsers what they should prioritise pre-loading), making the standard, non-SPA web even more performant. (And yes, some of this benefits SPAs too!)

Sure, you can argue some of this advancement may have been driven by SPAs and their apparent benefits. But there's some inevitability to all of this (both the appearance of SPAs and the advancement of HTTP) which makes the whole argument moot in my opinion.

As adoption and overall performance of the web platform increases, SPAs will even start to feel slow in comparison. Some feel slow already!

That's because so much of the heavy lifting is left to the userland threads of the in-browser JavaScript engine instead of the lower-level compiled languages, the ones used to build the core browser engine itself (C++, Rust, Swift etc).

That translates to a poorer experience in your app, and a penalty for your users.

While it's not impossible for JavaScript to be as fast or faster than the actual browser it's running in, it's just such a long way for it to get there it's a no-brainer at this stage to let the browser do what the browser does best instead of trying to replicate all of that in JS.

So don't! Use JavaScript the way it was intended: as a sugar-coating to enhance the pages, not to build entire pages.

I mean, you wouldn't eat a donut made entirely out of sugar, would you?

Again, in the extreme cases, maybe you would. Maybe for this donut-sized/-shaped sugar torus, you have an appropriately-sized dough-only counterpart, both of which you consume in close proximity...

I donut-know where this analogy is going.

¶So what's the alternative?

You, dear reader, are not in the most extreme case. Probably not even close! And you may never be.

So, if you haven't started building an SPA, don't!

Keep your code together in a single application where the front-end is rendered by the back-end, and then you can test and deploy it as a single unit. And yes, you can even do that without Docker 😱

Create it as a fully server-rendered, multi-page application with page reloads and everything. Go on! I double dare you.

If you really want/need the reactivity, try something like Livewire, Hotwire or HTMX.

You can do this all the way up to many millions of users per day and it will be fine, which you are a long way from.

Trust me, your front-end will never meaningfully need to move faster than your back-end, and vice-versa.

If you're already running an SPA and are contemplating bringing the two parts of the donut back together, do it! Bite your lip, close your eyes, and just do it.

Relevant

A-A-Ron!

Simon Hamp — Wed, 20 Sep 2023 00:00:00 +0000

Aaron Francis is a rising star in the Laravel community. Over the past couple of years he's rocketed up because he's a genuinely thoughtful, intelligent and funny guy.

I like him. I met him very briefly at Laracon US this year and I've had some great public and private interactions with him through Twitter. He's an awesome dude.

I follow a lot of really interesting, smart, funny people, and I respect them all. For me, Aaron is a little different though. I feel an affinity with him that I can't quite describe.

So many times he's said something on a screencast, podcast, tweet, or in person that I just can't help but do that "mmm-hmmm!" and nod affirmatively, knowingly.

He speaks to my soul.

Plus, he's been absolutely booting the (English) football out of the stadium lately!

He has called this his "Maximum Effort" era, but his approach to it is honestly aligning so hard with how I see things. He knows it won't - can't - last forever, but he's giving it his absolute best while he can. And I think it's paying off!

This isn't #hustlin' - it's hard work, balanced. I'm trying to do the same but I still don't get it right. Aaron is setting a great example, and sharing his lessons and mistakes openly and honestly, and I am here for it.

But he's a bit of a madman:

He started as an accountant - fully qualified, worked for one of the big accounting firms - but switched to programming early on in his career
Now he's got a full-time job at PlanetScale
He MC'd at Laracon US this year and absolutely smashed it!
He even closed out Laracon with arguably one of the best talks of the whole conference (video above - give it a watch) - I was moved. I could feel his emotion from the second row
He did a HUGE video course about MySQL (hopefully mostly on work time) - hours and hours of top-notch database content available for free! 🤯
He has a podcast or three, most recently Mostly Technical with Ian Landsman which I am really enjoying listening to
He just released an app - flowtone.app - with Boris Lepikhin
He tweets regularly about interesting topics and engages really positively with everyone, sending out positive vibes, especially in the Laravel community
He must have a hectic family life besides as he has young twins already and another set of twins on the way in a few weeks!

Huge props to his wife! She must be an absolute trooper and offering really great support and understanding despite having to care for two little ones and carrying two more besides all the usual stuff that life throws at women. Wow.

And I know that Aaron's working along with other talented folks, like Boris and Jason Beggs, so it's not just him slogging away - he's got help.

But Aaron deserves a huge hand for putting in the hours, pushing through the tough times, the self-doubt and mithering over which path to take, the 3am work sessions (I've been there too many times!)

👏

He's a fantastic example in just consistently being nice and thoughtful and positive - he is bringing the kind of energy I want. Which is hard for me: I'm a Brit, a realist and a sarcastic wotsit - a tricky combo to overcome!

And he has a lovely Texas accent which I am just so jealous of.

But you know what... even all of that isn't the whole story!

TODAY Aaron is launching another course, a 'meta' screencast all about screencasting¹! (use code LAUNCHFRIENDS for a $50 discount)

This time, it's a paid course that he has created and not for PlanetScale. And it looks incredible! I've been waiting very patiently for this one since he announced it a couple months ago for a number of reasons:

He has set a high bar for his own screencasts and others (me) rightly want to replicate that
I've been starting to do more video myself, so I want all those tips and tricks to elevate my own vids
He's been teasing it with little teardowns² of user-submitted videos and dripping some really practical, early access lessons for free
I just really appreciate the effort and polish he has put in and I think he deserves it, so I'm going to buy it

I'm hooked. I'm not just a follower of Aaron, I'm a fan ³! I'm excited for him and want him to succeed. That's a really rare feeling for me (and I feel super cheesy saying it!) - I generally want others to succeed, but I am usually happy being a bit of an armchair advocate.

With Aaron, I'm like: give me a placard, a bell, and fresh pair of lungs...

Well done, Aaron! You deserve it man.

This is an affiliate link ↩
He's promised to do a teardown of one of my own screencasts too, so I'm looking forward to seeing that - especially as that was possibly one of the most hastily put together videos ever ↩
Except for the fact that he's not a Star Wars fan and hasn't seen Andor - you need to watch that! Forget that it's even Star Wars... it's just great TV ↩

Getting background colours to go all the way

Simon Hamp — Thu, 14 Sep 2023 00:00:00 +0000

The problem
- Why is this happening?
- Back to why...
There is a solution!

I'm pretty proud of the Gitamic diff viewer. It's not perfect (and probably never will be thanks to different browser rendering engines), but it can handle some pretty gnarly diffs quite rapidly.

("Quite rapidly" being somewhat subject to your perspective)

Of course, a lot of this is down to browsers rendering engines getting faster and faster. So I can't really take any credit.

But it still took me a while to make it as quick as it is. One thing that I did learn tho:

Don't use a <table> to render a diff; They are slow as all hell!

One thing that I 'fixed' (again, subjective) the other day that I want to talk about now is the backgrounds on diff lines.

¶The problem

I really wanted the diff viewer to have all the normal visual cues you might be used to from other Git interfaces, like GitHub/Gitlab/Tower etc.

And for the most part, my first pass at that managed wasn't half bad: background colours, sticky line numbers, configurable context length, toggleable line wrapping...

But then one day I saw this:

¶Why is this happening?

Well, to explain that, it will help to set the scene a little, because... it's complicated.

Each diff is made up of lots of <div>s - "diff-divs", if you will:

the File Card - a panel that presents all the diff chunks from a single file in Git's index (these are collapsible)
a Chunk panel - a collapsible panel that renders a single chunk - n lines of changes plus context lines
the Line Numbers column
the Lines container - which will hold all of the lines and over which the Line Numbers column will appear to float
each line of the diff's content - basically one div per line of output from git diff

<div class="file">
  <div class="chunk">
    <div class="line">
      <div class="line-numbers">
        <!-- These are complex for layout reasons -->
      </div>
      <div class="context">
        <!-- This line of the diff -->
      </div>
    </div>
    <div class="line">
      <div class="line-numbers"></div>
      <div class="old"></div>
    </div>
    <div class="line">
      <div class="line-numbers"></div>
      <div class="new"></div>
    </div>
    <div class="line">
      <div class="line-numbers"></div>
      <div class="context"></div>
    </div>
  </div>

  <div class="chunk">
    ...
  </div>

  ...
</div>

This is simplified for the sake of this example. In reality, each div.chunk has more to it, which gives us further constraints that we also need to consider, such as its header.

(I know on the surface, this looks more complicated than a table, but trust me, your browser can render this wayyyyy faster)

Each div.file is a fixed-width card. This card is what creates that neatly contained, white background with a contextual heading. In diffs with many files, this helps the user spot that they're now moving to a different file, as they will see the one card end and a new one begin.

Fixing the width keeps the card completely visible within the available viewport. Nice.

However, each div.chunk needs to be set overflow-x: auto to allow long lines inside it to be seen and scrolled over.

If I were to set the overflow on div.file, then all chunks will be scrolled together.

That's not desirable from a UX perspective: when I'm looking at one chunk, I don't want another to be scrolling in and out of view.

What's more, for really big diffs, it will be the cause of some super janky scrolling.

And we'd also get a whole load of other visual regressions that would need to be solved, introducing even more complexity.

The backgrounds themselves (which are just background-color) are applied to the relevant div.line, based on its type: old, new, context, respectively.

(For those of you who want to make sure I'm not being completely psychotic - yes, these are generally well split into separate Vue components)

¶Back to why...

In HTML, when a container that has a background colour is inside another container that has a fixed width, the background colour rendering stops where the parent container stops.

This saves the browser from doing any work it probably doesn't need to do: calculating where the background should be rendering for any elements that in theory don't have anything visible outside of the visible viewport.

But, in practice of course, it's entirely possible for some child elements to "pop" out of their parent, especially when you explicitly allow a fixed-width element to overflow (e.g. with overflow-x: auto).

In that scenario, constrained children can appear to have their background clipped if other, wider children overflow the container and cause it to scroll.

It's not a show-stopper, but it's a little unsightly. Not exactly the experience I want for a premium add-on that folks will have paid for.

But the other - slightly more frustrating - problem this causes is that any sticky elements, such as the line numbers column, get trapped at that same point; wherever the parent container's 'official' width finishes.

So for lines that are considerably wider than the parent container's width, you could end up seeing this:

See how the line numbers columns stops and slides out of view early?

Why?

Because the sticky element can't jump out of its container - the parent whose width is fixed to a width that is incorrect.

So why not just let that parent container go full width?

That would result in the parent node (in this case, the File Card) being the element that manages the horizontal scroll... which we've already determined would lead to all of the diff chunks scrolling horizontally together.

And, y'know, it still doesn't solve the problem! There will still be some clipping, it will just be at a different place. In fact, just pushing the problem up the DOM tree only makes things worse for us.

Don't want. No good.

No, we need to solve this right here.

We might be able to introduce more complexity to the DOM and try to find some variation of divs that allows us to find some magical combination that meets all the requirements and Scotch-tape the whole thing together with a bunch of Javascript... but trust me, performance will suffer on a number of fronts, especially when rendering new diffs or redrawing during scroll.

¶There is a solution!

For me, the solution to this problem lies in combining good old CSS with just a sprinkling ✨ of Javascript.

I will admit tho, it's a tad disappointing that CSS can't solve this one alone for us yet - and sadly I'm not sure it ever will.

Basically, in order to force the background to stretch to the same width for all the lines, we need to explicitly tell the browser that they should all be 'yay wide'.

In other words, we have to apply a set width or min-width to all of them and not rely solely on the browser to work out how wide each div should be.

We could hard-code a very wide, fixed width to these to try to account for really long lines... that could even be done in pure CSS and with just a few extra bytes applying that width to the every div.line.

But then all chunks will be able to scroll... realllllly far... whether they need to or not (blerch) and I bet there will still be cases where one line goes just a little further than we've allowed for.

And besides, we've got these super powerful calculators rendering these views - it should be able to work out what the widest line is and make all of them the same width.... right?

But how can we find out what that width should be?

We could cycle through each element and find the longest one, but there are problems with that: if we have a lot of elements, it's going to be slow. Plus, if the elements aren't always there, timing is going to be an issue as we won't get the widths until they're fully rendered.

But, for argument's sake, let's say our timing issues are all solved and we can put up with a few extra milliseconds on the render time, how do we even get the full width of those long lines? It turns out that getClientWidth and getClientBoundingRects().width will only give us the visible width available to the viewport, not the full width.

Thankfully, the droids we're looking for are captured in the scrollWidth of the parent - that overflowing sonuvva, div.chunk, that has created this problem in the first place also has the solution hidden within the depths of its dark DOM-matrix!

scrollWidth is what the browser uses to determine how far the scrollbar needs to travel and how big the scrollbar handle needs to be. Thankfully, it applies it to the container that has the overflow-x, after it's determined how wide its currently-rendered contents are¹.

That means we can use it as the explicit width of all of the child elements! 🎉 Awesome!

It also means there's no need for us to run a loop over all of the n-long set of div.line elements.

We can just grab the scrollWidth value from the div.chunk and apply it as an inline style to each div.line:

<div v-for="line in change.lines" ref="lines" class="line">
  <!-- Line template code here -->
</div>

<script>
function recalcLineWidths() {
    this.$refs.lines.forEach((line) => {
        line.style.minWidth = `${this.$refs.chunk.scrollWidth}px`;
    });
}
</script>

(Again, this code is just for demonstration purposes. The actual logic is a little more convoluted.)

recalcLineWidths is executed at choice intervals when I know the line widths might have changed, such as when changing from wrapped to non-wrapped text.

It's still not perfect, but for the 90% use-case, where you just have some files that have really long lines, it does the trick.

This is coming to Gitamic in an upcoming point release soon.

For lots of lines, 'currently-rendered' will mean the timing of your call to scrollWidth matters immensely, because the value will be recalculated a number times over potentially thousands of nanoseconds. You need to wait until the very end of the render cycle. ↩

Laravel Nova Import v0.7

Simon Hamp — Tue, 12 Sep 2023 00:00:00 +0000

I recently spent a little time on my Laravel Nova CSV Import package, one of my main open source packages. This came at the request of a sponsor.

This gave me the opportunity to level-up some of the UI and spend some time diving into some of the open PRs and issues.

Please watch the video above for more details about the features that have been added, or check these changes.

The end result is v0.7. Yep, still not a v1. Even after over 4 years, I've not really had time to flesh it out and test it to get it to a point where it's stable enough to qualify as a v1.

Despite that, it's been downloaded over 200,000 times, which is staggering to me 🤯

Why Nova?

Laravel Nova is a great piece of premium software from the Laravel team and well worth every penny. I've used it since its release and it has made so many tasks easier.

It provides an excellent pluggable admin panel interface, which is brilliant for building internal tools or as a client admin for just about any kind of database-backed application.

What's more, it uses Vue (which I love), so building really rich UIs on it is dead easy, especially since Nova v4.

I've spent a lot of time with it and I'm proud to be a part of the Nova Internals group that is supporting David and Muhammad in evolving Nova into an even more powerful tool.

What about Filament?

I've been watching Filament closely and have even used it on a couple of projects. I am really excited for that team and the awesome work they're putting into the project seems to be paying off as I see and hear a lot of other engineers raving about Filament, especially now that v3 has launched.

I really like where that project is headed too and honestly I'm tempted to port CSV Import there if it's wanted.

The main difference, of course, is that Filament uses Livewire and Alpine in place of Vue. I love Livewire too and I'm using it more and more. I think it would be an good challenge to build out the two front-ends and maintain them.

The problem is time - or rather, the lack of it. I fear that I won't have time to maintain both versions concurrently, which means one will always be a little behind.

If an easy to use, powerful CSV Import tool is what the Filament community wants, I'd love to fill that gap, but let's see if that's needed.

Is a package really necessary?

If you can build this with your team for your use-case rapidly enough without needing to depend on a third-party package, I will always advise you to do so! Fewer dependencies generally means lower risk , which means fewer problems.

We've all experienced dependencies being left behind and going stale, maintainers disappearing seemingly without a trace and no way to get their attention, multiple forks all going in weird and wonderful directions... heck, I've been a bit like that with CSV Import!

But not every individual or team has the skills, time or resources to build and maintain a powerful CSV import tool - even though that might be what your client/business needs.

If you're already using Nova, CSV Import can have you importing CSV data into your database in minutes , with powerful validation and transformation, batching, and even asynchronous processing

That's a huge time-saver.

I guess the main concern is "will it still be around when we've moved onto Nova 5, 6, 7...".

The only sane answer to that is: Yes, if you can support its existence financially.

I believe CSV Import serves an important niche: folks who want an open-ended CSV import utility for admin panels they're building for paying clients.

As a completely free and open source package, there's literally nothing forcing anyone to contribute anything for the effort that I've put into it over the years.

All I ask is that if it serves you and enables you to save money or make money by adding this powerful feature to the tools you're building, please consider sponsoring my efforts - even with just a small one-off amount - every little helps!

I will be extremely grateful.