First of all, thank you for reaching out and asking the community a question like this, because I think there are a lot of people in this boat.
TLDR; The short of it is - if you are interested in building other sites further down the road, then you would be wise put the work in and build the booking site yourself. It will take time, so you will definitely need to think about long term implications.
However, if you are not really interested in building other sites, or you have other really pressing concerns that need your time, it would be best to engage the original web developers to see if they can update the site which would free up your time. The flip side is they might say the whole site needs an overhaul due to such and such not being secure anymore, or whatever their excuse might be, so it could take time and cost more than you expect. Watch out for ballooning costs and make sure you get a clear plan down before agreeing anything.
-
If it were me, I would build the site myself. But, there are a couple of things you need to consider (and this is coming from my experience working with on the web for around 26 years, and as a pro webdev for nearly 20 years).
This is a slightly long post (sorry, I truly did not mean to write an essay) but I hope that it will quell your concerns, encourage you, and help you on your journey as a webdev.
The first point is about time - if you ask this other team to update the site, you will have more time to do other things. If you have something else that is important to you, that you need to attend to, then it would make sense to ask that team to do the work. I suspect they will likely tell you the site needs to be totally re-written somewhere along the line, and it might turn out to take more time and money than you expect, but at least you would be free to pursue other things.
The second point I would raise is that if you build the site, you have to maintain it. If you build the site well, you can sleep at night. If you don't, you might get a call at 8pm before you are thinking about finishing for the day saying there is some problem with the site. In fact, even if you build the site really well, you will still get edge cases where someone will inform you of an issue, with limited information, you may end up spending hours to work out what the issue is (and indeed, if there even is one). I've experienced this a couple of times over the years, fortunately it's very very rare, but it's always a possibility.
Considering the two points above, if you decided to build the site yourself, I would have the following suggestions:
Build the site with SvelteKit, FaunaDB and CloudFlare (Workers and CDN). There are a LOT of tools around, and there are always new ones just around the corner, but working with the above tools has been a game changer for me. This is all serverless based. It has the capacity to serve hundreds of thousands of simultaneous users in a way that PHP/MySQL could only dream of (and PHP/MySQL has been my bread and butter for most of my webdev career).
It does this at a controlled cost :
(CloudFlare Workers) In quiet times it scales down, you pay almost nothing to keep things going, and when the site is busy it scales to support the users, however as many as there are. Many firms have made this claim over the years about various tech, but I think that with Cloudflare Workers it really is true. Performance is fast, reliable, it scales smoothly, and cost is kept in check.
I notice you have put Deno in your stack which is a V8 runtime (I think this is pretty much the same as Cloudflare Worker’s V8 runtime, though someone correct me if I am wrong). I have no experience with Deno though.
Less time is needed to maintain servers :
I have a few sites on a hosting provider in the US where they manage the servers, I’m also using AWS where I have to maintain the servers. The reason I use AWS is because I needed sites served in Japan, on a fast backbone, and because I was PHP/MySQL based they seemed to have everything I needed (I looked at a lot of other TRADITIONAL hosting options here in Japan, but AWS reliability, scaleability and functionality simply beats them all, even if it is not the cheapest).
There are some issues though. If you have a site that is going to be potentially very very busy (even for short periods of time) you need to set up load balancing. There are various ways of doing this on AWS, trying to figure out the best reliability/performance/cost path is not easy - I read so much documentation I started dreaming about it. If you have load balancing in place, and the site is not busy, you are burning money. On the other hand, if it cannot support the current number of users, you have to scale up quickly, preferably before you get into that situation otherwise you are going have a poor user experience (which I truly dislike) and will lose customers.
Of course, for best performance (and control of costs), you would probably set up your own server via EC2. You have to maintain that server. I’ve never had a server go down, fortunately, but it’s certainly a possibility. You have to maintain that too.
This all takes up valuable time. It’s not a marketing thing, it’s a real down to earth problem that is solved going the severless route. It really truly does. Which is why I recommend Cloudflare.
Why Svelte? (or, how did I get here) :
I’ve written several large web applications from scratch over the years. I amassed a large library of my own modules that I have refined over the years including tools to support the development process itself (performance, trace, logging, etc).
For about a year or so, a decade ago, I used Drupal 6/7 (which was a nightmare for many different reasons, and caused lock-in). I built several sites with it, but it always seemed to require more work and had a lot of issues with maintainability later on (I bring this point up, because I have experienced the ‘promise’ of new tech several times, Drupal was one of them).
After this I ended up building my own framework from scratch in PHP because I wanted to make sites I built as fast and lean (yet fully featured) and be the least memory intensive as possible - in order to serve as many concurrent users as possible. Full user account management, security with roles, forms that build themselves (pretty much) because the system knows how tables are related (I was really proud of this because I could build a form programatically with just a few lines of code, fields are protected from invalid input, user access controlled view/edit, etc.) I designed the whole stack setting up my servers on AWS, tuning Apache and PHP to be as fast as possible. Memory use for building a fully constructed page was under 2mb, and generation took a millisecond or so (actually can’t recall the exact number, but it is VERY fast).
I spent over half a year last year working every day. I mean, truly, every day. I didn’t have a single day to stop and rest for over half a year because there just wasn’t time.
Towards the end of last year the project got paused for various reasons. It was used for demos to clients, which was immensely important for our business, but was not put into full production as it wasn’t 100% finished. I took a break. Worn out, and pretty disappointed.
I bring this up because when you put a lot of hard work into something, you don’t usually want to let it go. There has to be a damn good reason to take another path after that.
Over the years I looked at many different frameworks, CMs, and other curiosities - each time wondering "would it be worth investing time in this?" After being burned by Drupal many years ago, I had pretty strong reservations about locking myself into someone else's code base.
Earlier this year I started on a new project - I had all my tools I had already built. I could build the new site in around two months with all the existing tech I had, and I would probably have much free time to myself. Having designed the new system, prepared the database, I starting thinking about improving the page design and better user interaction (of all things right?) I looked at various javascript frameworks. My thinking was - I’ve got the server side down, I’ve got the content management down, let’s see what more we can do with the front end. And I discovered Svelte. I saw Richard’s demo from back in 2017. My world exploded from that moment on (where the hell had I been?)
It needs a serverless server (I’d heard of these and it didn’t make much sense to me way back when - losing control of the servers, who would possibly agree that was a good idea?) However, I looked into it more, and ‘saw the light’ so to speak.
While there are a lot of options I decided that ultimately Cloudflare made the most sense to me. And the journey began.
The point of all of the above post is that I am not one to jump ship. I am not interested in the latest fad. There needs to be something truly substantive for me to decide to invest the time needed to move to a different stack.
I still haven’t answered the question - why Svelte? You might wonder - why on earth would I change after all that hard work I had already done for my PHP based framework (which actually has a Javascript side with lots of modules for different things as well), to using Svelte?
Because it is, in my opinion: the future of webdev.
Yes, there might be a new framework years down the line that could take over (never say never) but right now it is so well thought out, so well put together, and so forward thinking, it just doesn’t make sense not to invest time and use it.
It’s similar to a few other frameworks (next, react, etc), but different enough, that it’s a totally different beast. The amount of code you have to write is lower, readability is better (this is REALLY important, and many programmers learn way late in the game how to write code that is readable - we often get stuck on performance; readability be damned).
Code manageability is great, separation and modularity of code is pretty good, I’ve been very impressed with it.
Now that you can understand a bit of my background, and my journey here, I’m going to try to answer some of your other questions.
If you build the site yourself, you are not just committing to building the site, you are also committing yourself to building other sites later down the road (otherwise it is likely not worth the amount of time you will have to put in to building the booking site.)
Given how functional the Svelte, FaunaDB, Cloudflare stack is, if you get the stack down, then future development time will be significantly reduced, and the sites you build will be fast and robust. The bonus is that you won’t have to keep an eye on them in quite the same way you would have to in a traditional non serverless hosting environment, costs are kept low, performance is good, and you can serve how ever many users you need to. Less stress, more time.
Both Svelte and FaunaDB are young. They are still developing, but I like the direction they are taking, and I think they are likely to take more and more market share of the webdev sphere - so having a good knowledge of them will most likely serve you well into the future.
There are a couple of holes in Svelte at the moment. Internationalisation for example is not really there, encrypted cookies with Svelte and Cloudflare was problematic for me as one of the usual Cookie modules for Svelte (not a standard inbuilt Svelte module, but something written by a contributor) uses an encryption module that is not compatible with Cloudflare (so this is really an issue with Cloudflare). Their VM is not 100% Node compliant, just so you know. Despite the issues I have had, I’m still steadfast in my belief that this is the right direction to take.
I hope that this post is useful to someone. If you have questions, just ask!
Good luck with whatever you decide.
Edited to correct "CloudFlare (Works and CDN)"; and later to correct formatting.
Svelte
