NEW TOPIC
THIS TOPIC IS NOW CLOSED
AS IT WENT OFF THE ORIGINAL TOPIC
https://scratch.mit.edu/discuss/topic/482869/

I have doubt that the Scratch team would add a third party viewer to Scratch. However, you are free to link it in your projects as a faster alternative.

no like implement it maybe work with it I'm not saying they keep turbowarp in charge of the code

pokeshah wrote:

no like implement it maybe work with it I'm not saying they keep turbowarp in charge of the code

Scratch could just write another compiler for the code.

Vercte wrote:

pokeshah wrote:

no like implement it maybe work with it I'm not saying they keep turbowarp in charge of the code

Scratch could just write another compiler for the code.

exactly but that's what I was saying about it being hard boring and repetive

pokeshah wrote:

Vercte wrote:

pokeshah wrote:

no like implement it maybe work with it I'm not saying they keep turbowarp in charge of the code

Scratch could just write another compiler for the code.

exactly but that's what I was saying about it being hard boring and repetive

It's unseeable code, just for the sake for making it run faster. Why would they make a seperate page when they can make improvements on the current one?

Vercte wrote:

pokeshah wrote:

Vercte wrote:

pokeshah wrote:

no like implement it maybe work with it I'm not saying they keep turbowarp in charge of the code

Scratch could just write another compiler for the code.

exactly but that's what I was saying about it being hard boring and repetive

It's unseeable code, just for the sake for making it run faster. Why would they make a seperate page when they can make improvements on the current one?

what no I'm asking if we could get a better compiler I don't care if it gets 50% faster every month I'm not asking it to be done in 1 go

pokeshah wrote:

Vercte wrote:

pokeshah wrote:

Vercte wrote:

pokeshah wrote:

no like implement it maybe work with it I'm not saying they keep turbowarp in charge of the code

Scratch could just write another compiler for the code.

exactly but that's what I was saying about it being hard boring and repetive

It's unseeable code, just for the sake for making it run faster. Why would they make a seperate page when they can make improvements on the current one?

what no I'm asking if we could get a better compiler I don't care if it gets 50% faster every month I'm not asking it to be done in 1 go

Scratch does not work with TurboWarp, and why make it an extension when you can implement it itself into the main scratch?

I believe TurboWarp converts the projects into Javascript, which means that things may not run as they are supposed to. I mean, the point of Scratch is to code with blocks and those blocks running the project, not coding with blocks and those blocks being converted into a completely different programming language in which the project runs on.

LegoManiac04 wrote:

I believe TurboWarp converts the projects into Javascript, which means that things may not run as they are supposed to. I mean, the point of Scratch is to code with blocks and those blocks running the project, not coding with blocks and those blocks being converted into a completely different programming language in which the project runs on.

Here's a secret: Scratch also converts the projects into JavaScript.

The difference is in how they do it. Vanilla Scratch is an interpreted language, which means that in real time, the interpreter (written in JavaScript) steps through the code and runs each block as Javascript. Interpretation has a number of benefits, the primary one in the Scratch environment being that scripts can be modified as they run, but the primary downside is that interpretation tends to be slower than the alternative, compilation.

Phosphorus and all of its derivatives (Sulfurous, Forkphorus, TurboWarp) do something called just-in-time compilation (JIT) - in this case, this means that the program is compiled (run through and converted to JavaScript all at once) when the user clicks the Green Flag, and it then runs when compilation is complete. Scripts cannot be edited without recompiling the program, but compilation, along with a number of other improvements and optimizations over Vanilla Scratch, make TurboWarp far faster. I'm sure you've used TurboWarp, right? So far I haven't run into a single project that didn't work right on TurboWarp.


As for the suggestion itself, the only benefit that I could think of is being able to use Scratch's cloud data servers with TurboWarp (currently TurboWarp has its own cloud data servers). It wouldn't exactly be hard to do, since TurboWarp is completely open source and is essentially a drop-in replacement for scratch-vm and scratch-render (and to an extent scratch-gui), but is there really a point? Is it that hard to copy the project URL, go to turbowarp.org, and paste it in? It takes like 10 seconds. If you use it enough, you could probably even write a userscript to modify the URL for you.

Also, stealing the TurboWarp source code would be incredibly rude (but completely legal) on the ST's part.

LegoManiac04 wrote:

I believe TurboWarp converts the projects into Javascript, which means that things may not run as they are supposed to. I mean, the point of Scratch is to code with blocks and those blocks running the project, not coding with blocks and those blocks being converted into a completely different programming language in which the project runs on.

Scratch doesn't run on Scratch. It runs on js.

Flowermanvista wrote:

LegoManiac04 wrote:

I believe TurboWarp converts the projects into Javascript, which means that things may not run as they are supposed to. I mean, the point of Scratch is to code with blocks and those blocks running the project, not coding with blocks and those blocks being converted into a completely different programming language in which the project runs on.

Here's a secret: Scratch also converts the projects into JavaScript.

The difference is in how they do it. Vanilla Scratch is an interpreted language, which means that in real time, the interpreter (written in JavaScript) steps through the code and runs each block as Javascript. Interpretation has a number of benefits, the primary one in the Scratch environment being that scripts can be modified as they run, but the primary downside is that interpretation tends to be slower than the alternative, compilation.

Phosphorus and all of its derivatives (Sulfurous, Forkphorus, TurboWarp) do something called just-in-time compilation (JIT) - in this case, this means that the program is compiled (run through and converted to JavaScript all at once) when the user clicks the Green Flag, and it then runs when compilation is complete. Scripts cannot be edited without recompiling the program, but compilation, along with a number of other improvements and optimizations over Vanilla Scratch, make TurboWarp far faster. I'm sure you've used TurboWarp, right? So far I haven't run into a single project that didn't work right on TurboWarp.


As for the suggestion itself, the only benefit that I could think of is being able to use Scratch's cloud data servers with TurboWarp (currently TurboWarp has its own cloud data servers). It wouldn't exactly be hard to do, since TurboWarp is completely open source and is essentially a drop-in replacement for scratch-vm and scratch-render (and to an extent scratch-gui), but is there really a point? Is it that hard to copy the project URL, go to turbowarp.org, and paste it in? It takes like 10 seconds. If you use it enough, you could probably even write a userscript to modify the URL for you.

Also, stealing the TurboWarp source code would be incredibly rude (but completely legal) on the ST's part.

So yeah I had no idea TurboWarp was opensource or it compiled like that oh and the source codes on GitHub it would just be copy-pasting i take back my it would be hard it would probably take a few hours max
I thought scratch used python or something slower than js



If you didn't understand @Flowermanvista
Heres What he said simplified
There are 2 main types of compilers
1 type is converting to js line by line(block by block)
the second type is converting to js all at once
converting to js at once is faster but you can't modify the code because it already compiled the output won't be based on what blocks you have but the compiled output would be running on the compiled js
while scratch that uses line by line would compile line by line so in a repeat loop the block would be compiled as many times the block is run
Real-World Example:
You get a flyer at your door you see the prices of the vegetables you need (compiler is looking at the code)
You can either go to the mall and get everything you need at once and never go till you have to go again(all at once compiler)
or you can get some stuff go a few days later when you go to the story you see the prices change then you buy what you need for the next two days(line by line compiler)
In the all at once compiler, you saved more time(ran faster)
but, In the line by line compiler, you got the price change (not the best example but the prices(values) changed but took longer (ran slower))



Wow this was wordy

I’d like to comment that turbowarp can be laggy or maybe that’s my device

Flowermanvista wrote:

-snip-

That's probably the best explanation I've heard in my life of anything

pokeshah wrote:

There's this unofficial mod called TurboWarp and it runs 1000x times faster…

No, it just compiles the project code into Javascript. and has a better pen and a 60 fps mode.

on scratch 10000x faster and my project Upgraded!

It doesn't make the project go faster, it just compiles the code differently.

Vercte wrote:

-snip-

Scratch does not work with TurboWarp, and why make it an extension when you can implement it itself into the main scratch?

Exactly. And, to the topic owner, what do you mean by extension? A Google Chrome extension, or an extension like “Pen” and “Text-to-Speech”. And, like @Vercte said, what's the point of not actually implementing it?

sportfan999 wrote:

pokeshah wrote:

There's this unofficial mod called TurboWarp and it runs 1000x times faster…

No, it just compiles the project code into Javascript. and has a better pen and a 60 fps mode.

on scratch 10000x faster and my project Upgraded!

It doesn't make the project go faster, it's just that there is no Social Media on Turbowarp, so there is no lag.

Vercte wrote:

-snip-

Scratch does not work with TurboWarp, and why make it an extension when you can implement it itself into the main scratch?

Exactly. And, to the topic owner, what do you mean by extension? A Google Chrome extension, or an extension like “Pen” and “Text-to-Speech”. And, like @Vercte said, what's the point of not actually implementing it?

No, TurboWarp doesn't run projects faster because it doesn't have the social aspect.
It runs faster because it interprets each block before it runs, unlike Scratch, which procedurally interprets each block as it runs, creating unnecessary delays.

if you want a quick way to use turbowarp, you can just use this bookmark trick: javascript:url=window.location.href;window.open("https://turbowarp.org/#"+url.substring(33)) <– copy this, create a new bookmark, paste this as url, title open in turbowarp, and done!

I think what @pokeshah means is the scratch team make their own compiler like turbowarp. not using turbowarp, but implementing something very similar to replace the current compiler.

how do you get the project on turbowarp

i don't know why super scratch smash also sometimes cannot work in turbowarp too..

Sorry, but no support. TurboWarp is a compiler, but it works better because it doesn't have to load comments, views, loves, favorites and remixes