You need to use the Knit Game Framework(A template to help get started using Knit)

[nakoyasha (Haruka)]

From experience, Knit just slowed me down in development compared to just using RemoteEvents and normal scripts. It just over-complicates things imo (especially with its server-client communication model, which creates a mess of a stack trace with more required scripts).

[TopBagon (Bagon)]

I’m glad you made this. Knit is an awesome framework that I use in every project I work on.

I made a fairly complex trading system without knit once, it was a painful experience… I had like 10+ line of code just referencing remote events and then some other mess. I remade the system in knit few months later and the code was much cleaner/easier to understand, implementation took less time and it worked better overall. Knit also comes with some useful utility modules like janitor, promise, signal, TableUtil, etc. They are essential to me and not having to manually insert each of them is rather handy.

I could go on all day but in a nutshell it’s a super helpful framework and I definitely recommend it to anyone.

[ForcyDorcy (Konstantine)]

Knit’s networking system is only one of it’s features. It is pretty powerful and gives you the ability to implement inbound and outbound middleware functions which you can use to drop requests or serialize data.

The real benefit that comes from using Knit is how the code communicates with each other; it turns more into a discussion about single script architecture vs having a million scripts everywhere. Knit is a powerful framework for single script architecture workflows.

Roblox-TS simply transpiles TypeScript into Roblox Lua and isn’t at all some kind of alternative to Knit. In fact, Knit is very popular among Roblox-TS workflows.

Hope that clears things up.

[ForcyDorcy (Konstantine)]

Knit’s networking system returns Promises, so, you can implement your own system for catching errors!
Promises do have a pretty long chain in Knit, but I’ve found that they help me pinpoint exactly where these errors are happening in my code.

[chainreactionist]

Just added the video to the post.

[OminousVibes0 (OminousVibes)]

I would have to disagree with your statement. As a developer who uses Roblox-TS, it isn’t a framework at all. It’s a compiler that converts Typescript into Roblox Luau. Which, of course, does not stop you from using Knit within Roblox-TS.

The benefits of using Knit are apparent once you use it. It follows the idea that the main scripts controlling your code are singletons (Controllers and Services). Those who have previously used AeroGameFramework (or Flamework for Typescript users) should be somewhat familiar with this concept. However, the client has access to certain functions and data the developer intentionally exposes within a service, which allows the client to call server functions far more intuitively. Knit follows Roblox’s style of Singletons, and you can retrieve services and controllers using:

// Service:
Knit:GetService("ServiceName")

// Controller:
Knit:GetController("ControllerName")

There are also in-built packages that would be very useful for developing (such as Janitor, signals, table utility, and more). It’s also much easier to read as it splits your game into very readable singletons. I’d recommend any Roblox developer that codes in Lua to use Knit.

However, as a Roblox-TS user, I prefer Flamework (another framework) over Knit as it is designed explicitly for TS and follows TS guidelines better.

[OminousVibes0 (OminousVibes)]

cc: @TayIorRobinson
Hopefully the reply I made above can explain the appeal of Knit to many developers.

[wravager]

Many developers don’t need to see the appeal of Knit as it just makes creating stuff more complicated. A basic few lines of code can make client-server connection simple and easy without needing the clutter of a whole “Game Framework” to do it.

A small example of how simple it needs to be:

local functions = {}
RemoteEvent.OnClientEvent:Connect(function(called, ...)
	if(functions[called])then
		functions[called](...)
	end
end)

local FireEvent = function(call, ...)
	RemoteEvent.FireServer(RemoteEvent, call, ...)
end

This is Roblox we are talking about, almost everything you can make can be done simply in a few lines of code. This is why I never understood the appeal of massive frameworks when most developers are not creating huge, over the top games 99% of the time.

Few other opinions that I think share the same feeling.

@M_nzter

I’ve looked at Knit a few times and still never really understood the appeal behind using it.

From reading the Knit Documentation & your Post, it seems like the core appeal of Knit is that it saves you time/confusion of having to create RemoteFunctions & Events.

@TayIorRobinson

Of course, if it works for you, use it, don’t let me stop you! But most of the reasons suggested in the OP can already be done with much simpler libraries & functions

@M_nzter

Considering how minuscule the benefits of using this Framework seem to be, hopefully, people really compare those with the downsides before using it, or you could get really deep into a project and then regret it.

@mariidev

From experience, Knit just slowed me down in development compared to just using RemoteEvents and normal scripts. It just over-complicates things imo (especially with its server-client communication model, which creates a mess of a stack trace with more required scripts).

td:lr This most likely will not appeal to many developers on a platform such as Roblox.

[OminousVibes0 (OminousVibes)]

I can understand the sentiment. Knit does not make stuff more complicated, though, so unless you’re making a very bare-bones basic game, the Knit framework doesn’t affect code complexity as much as you may believe.

@wravager

A basic few lines of code can make client-server connection simple and easy without needing the clutter of a whole “Game Framework” to do it.

Regarding networking, the snippet you provided honestly looks less appealing than if one was to design it with Knit.

Ex, Knit Service with networking:

local Knit = require(game:GetService("ReplicatedStorage").Packages.Knit)

local MyService = Knit.CreateService {
    Name = "MyService";
    Client = {};
}

function MyService.Client:CallableFunction()
end

function MyService:KnitStart()
end

function MyService:KnitInit()
end

return MyService

@wravager

This is Roblox we are talking about, almost everything you can make can be done simply in a few lines of code. This is why I never understood the appeal of massive frameworks when most developers are not creating huge, over the top games 99% of the time.

That’s precisely one of the reasons many developers like Knit. The exposed framework is not nearly as massive as you might imagine! Knit is almost excessively unopinionated and can just be used as a utility.

@wravager

td:lr This most likely will not appeal to many developers on a platform such as Roblox.

I must also disagree with you there, Knit is getting a minimum download of dozens weekly. Even reaching up to 280 and more! This is merely the downloads for the Typescript version as well, if we also count the downloads of the main package, I’m sure there will be an impressive amount of developers using Knit.

I do know that there is a possibility of re-downloading and etc, but even if we only count 25% of the total, it will still remain a sizeable amount.

To sum it up, while some of the structuring benefits are less evident when working on more simple games, there aren’t any drawbacks to using Knit either!

[M_nzter (MonzterDEV)]

I already said Roblox-TS wasn’t the same as Knit at all

@M_nzter

I made the slight comparison to Roblox-TS because it’s the closest thing I’ve seen in the community, which does actually provide significant advantages, but I believe it is also very different than Knit

Even with your explanation of Knit, I still cannot see why it’s worth a competent Developer’s time to learn the entire Knit framework, to simplify already simple things.

Lets looks at the normal vs Knit example

Normal

@wravager

local functions = {}
RemoteEvent.OnClientEvent:Connect(function(called, ...)
	if(functions[called])then
		functions[called](...)
	end
end)

local FireEvent = function(call, ...)
	RemoteEvent.FireServer(RemoteEvent, call, ...)
end

Knit

@OminousVibes0

local Knit = require(game:GetService("ReplicatedStorage").Packages.Knit)

local MyService = Knit.CreateService {
    Name = "MyService";
    Client = {};
}

function MyService.Client:CallableFunction()
end

function MyService:KnitStart()
end

function MyService:KnitInit()
end

return MyService

The normal really isn’t much different than the Knit one. It’s not significantly larger than the Knit one, (it’s actually smaller).

@OminousVibes0

To sum it up, while some of the structuring benefits are less evident when working on more simple games, there aren’t any drawbacks to using Knit either!

I also believe you’re extremely wrong here. To say Knit has absolutely no drawbacks is either ignorance or disingenuous.

Frameworks that aren’t extremely simple and are fully implemented into your Codebase, will certainly require any new Team Members you invite to take their time and first learn how to use the Framework.

Since you seem so passionate about Knit, maybe you should try explaining further how it would actually help Developers. The previous explanations you created still didn’t make me see any advantages at all from the Framework. It feels like you’re pushing Knit as being a revolutionary Tool for Roblox Devs, like Rojo, and for that to be true, Knit must do a much better job at explaining what benefits it can actually offer the majority of Roblox Developers.

[jonbyte (Jon)]

Disclaimer: I am a fan of the creator of Knit and have nothing against the framework itself.

I am not sure of the full capabilities of what Knit can do but I do have some comments regarding networking. Roblox already massively simplifies and abstracts stuff dealing with the network. Frameworks that wrap this system could arguably make it more complicated than it has to be.

I am also sure other people can agree with me that they don’t like wrapping their entire game in a framework in general (depends on what people consider a framework).

Again I have nothing against any frameworks or their creators, I just have opinions on if they are actually of use to myself. If anyone is interested in using Knit there is no shame or issue in doing so.

[OminousVibes0 (OminousVibes)]

@M_nzter

I already said Roblox-TS wasn’t the same as Knit at all

I’m pretty sure you did indeed imply that Roblox-TS is a framework. As shown here:

@M_nzter

The only similar ‘tool’ to Knit I’ve seen is Roblox-TS. If I was going to invest time into using a Framework, which would require time learning it all, I believe you’d benefit much more from investing that time into learning Roblox-TS.

---

@M_nzter

The normal really isn’t much different than the Knit one. It’s not significantly larger than the Knit one, (it’s actually smaller).

In regards to this point, don’t forget that you still have to instantiate events and the events very loosely organized. While in Knit, the only code needed to make a remote event is:

function MyService.Client:CallableFunction()
end

The rest of the code I’ve shown are just rather simple bootstrap code that may be used for more features.

---

@M_nzter

I also believe you’re extremely wrong here. To say Knit has absolutely no drawbacks is either ignorance or disingenuous.

Please remember to keep your tone polite here. I say that Knit has absolutely no drawbacks is because it takes only 2 minutes for experienced developers to understand how to use someone else’s Knit code in theirs. Not to mention that new team members don’t even necessarily need to know Knit to assist development progress (As previously mentioned, whether something should just be a script or a Knit singleton is completely up to you)

---

@M_nzter

Since you seem so passionate about Knit, maybe you should try explaining further how it would actually help Developers. The previous explanations you created still didn’t make me see any advantages at all from the Framework. It feels like you’re pushing Knit as being a revolutionary Tool for Roblox Devs, like Rojo, and for that to be true, Knit must do a much better job at explaining what benefits it can actually offer the majority of Roblox Developers.

I’m afraid you misunderstood my intent here. I’m pushing Knit as a useful and optional tool for developers to use for organizing code and events. The usage (or lack of usage) of Knit purely depends on your personal preferences. I’m mainly explaining why people like Knit. Personally, I don’t even use Knit, I use Roblox-TS and Flamework to make my games.

[ADRENALXNE (Dev1n)]

I think one big takeaway from Knit is the components module. It’s very powerful and basically makes Roblox the source of truth for your code and manages state very well. It’s pretty much the same thing as Quenty’s Binders (and maybe with some add-ons, but idk) if you are aware of those.

[CmdrRaine]

It looks like you have removed the second video tutorial from YouTube, Do you have another link to it?

Dan

[chainreactionist]

Knit Tutorial (Studio)

Knit Tutorial (Rojo/Wally)

He moved it to his main channel.

[NinjoOnline]

Highly recommend using Knit! Incredibly useful and makes the speed and process of development a million times better than messing with remotes and bindables. Games would normally take me 4-5 months to code. Using Knit, I’ve managed to code games within a week. Insanely useful, can’t recommend enough

[inkiramind]

Very nice framework. But I recommend rewrite it to your needs (Also I recommend remove promise at start and yield thread instead).
Yes, you will need some time to make great structure, but this is indeed worth it.
If you need medium/big project with transferable services, your answer is knit.
If you just make something small I think it’s really overkill (Not apply if you have knit services from past project). Just imagine that you write something like:

require(game:GetService("ServerStorage").Path.Path.Path.Path.ServiceName) 

instead of:

Knit.GetService("ServiceName")

[chainreactionist]

I found that for most people it is very overkill to try to start a Knit project because of the practically infinite setup time it takes if you let it. My solution to this is to work on a new template called C.G.T(Chain Game Template) that includes essential services and controllers that all games require and a general structure that allows you to just jump in and get started on a new project. If people are interested in that they should look forward to that, I’m a bit busy so a general release should be expected in a few weeks to a month from now.

[inkiramind]

Good, keep us inform. I am interested because I want to know how other games structure their services/controllers

[TheH0meLands]

Knit genuinely is one of the best modules I’ve ever seen. Like ROACT LEVEL GOOD. Normally i’d have to create a localscript inside a folder. Then add it to me default.project.json. Then create a remote event.

But knit completely eliminates that and I can do server-client communication within 1 script. Amazing module 10/10