+2 votes
by (380 points)
I'm just learning Sugarcube, and I'm trying to figure out the difference between a widget and a custom javascript macro. The widgets are super intuitive and easy to use, what would be the incentive for learning to make macros in javascript?

Thanks everyone!

3 Answers

+2 votes
by (63.1k points)
edited by

In general, macros are faster than widgets, and allow for greater complexity and more options. I recommend widgets for cutting down on repeated code chunks, and macros for adding new functionality, but if you can / want to use widgets instead, that's not really that big a deal. Your comfort level with JavaScript may also be a factor worth considering too; if JavaScript looks like gibberish and you don't think that's likely to change, there's nothing inherently wrong with sticking with widgets. 

See this thread on the old forums for more. 

+2 votes
by (8.6k points)
edited by

There are only a few cases where you have to use a macro, because widgets can't replicate the functionality. Those have to do with structures like

<if>...<elseif>...<else>...</if>

<for>...<break>...<continue>...</for>

<switch><case>...<case>...<default>...</switch>

Essentially, whenever you have sub-macros inside a macro (and the "for" case is especially complex here). In addition, widgets can't deal with "naked" parameters with "uneven" quotes (whereas macros can, via the "skipArgs: true" option), so replicating something like <<set>> with a widget is not quite as easy without changing the syntax.

Other than that, it's down to personal preference, comfort level when dealing with JavaScript and performance reasons.

by (68.6k points)
edited by

In addition, widgets can't deal with "naked" parameters, so replicating something like <<set>> with a widget is not quite as easy without changing the syntax.

That's incorrect, actually.  The <<widget>> documentation does mention how to access the whole argument string, in both its raw and parsed forms—though it doesn't tell you what to do with it, since that could be almost anything.

by (8.6k points)
edited by

@ TheMadExile Right, I misremembered - it was about the inability to deal with "uneven" quotes, but macros can't deal with those either, so that's a wash. Fixing my answer accordingly.

EDIT: Scratch that, I just now remembered about skipArgs. Need more coffee.

by (380 points)

Wait, you can't use sub-macros inside a macro? Because I've got a macro setup like this:

<<widget "test5">>
	<<if $var eq 5>>
		it's 5
	<<else>>
		it's not 5
	<</if>>
<</widget>>

...and it works just fine. The for loop works too. Are you referring to something else?

by (8.6k points)

@cakebread: What's meant is doing something like the <<if>>...<<elseif>>...<<else>>...<</if>> macro set ("if" macro with two sub-macros, "elseif" and "else") or something like the "request" macro I posted (a simple version of) in here: https://twinery.org/questions/878/help-with-a-custom-macro-porting-from-jonah-to-sugarcube-2

+2 votes
by (68.6k points)
edited by
Basically, the differences boil down to two things: the code you write them in and widgets are self-closing/void only--i.e. they cannot be containers/have closing tags.  Unless you really need the ability to have a closing tag, and possibly child tags, widgets are generally just as good as macros, so use whichever you're more comfortable with.

Some people try to make a big deal out of performance, however, most of the time they're either blowing smoke or, in cases where they do attempt to measure performance, they're not actually measuring what they think they are.  I wouldn't put too much stock into performance concerns.
...