A discussion of what WebLink is, and is not
That's sounds great, but it's about as accurate as describing a car as a pothole creator. Well, here in Detroit that's more true than not, especially on Van Dyke ... but I digress.
Here's an example of using VBScript in a WebLink application:
function HitMe ()
Set pfccomglob = CreateObject("pfc.MpfcCOMGlobal")
mdlname = pfccomglob.GetProESession.CurrentModel.FileName
Document.getElementById("mdlname").innerHTML = "Name: " & mdlname
msgbox("Name: " & mdlname)
<INPUT name="a" type=button value="Hit me!" onclick="HitMe()">
To make matters worse, you don't even need to use the web browser! A Pro/Toolkit DLL can access the WebLink COM objects using C/C++ and can do so completely outside the confines of the web browser. The Pro/Toolkit DLL could also go as far as hosting your favorite scripting engine. The web browser is just one of many environments in which a WebLink application can run.
Here's the same example using Perl to access WebLink COM Objects from within a Pro/Toolkit DLL:
$pfccomglob = Win32::OLE->new('pfc.MpfcCOMGlobal');
$mdlName = $pfccomglob->GetProESession->CurrentModel->FileName;
Can you imagine the response had they called it Pro/COM, or ActiveXLink, or COM.Link? A resounding "huh?" would have echoed through the halls on Kendrick Street. I think the marketing guys got it right this time.
Anyway, using whatever language in whatever environment you desire, the huge benefit to WebLink is that it's a rapid prototyping system for Pro/Engineer applications. The code-test-code-test cycle can be repeated as quickly as you can refresh the web browser. Whether you intend to migrate the application to JLink, or leave it in the web browser, you can get a complex application written very, very quickly. That's what makes WebLink very powerful.
Learn it, you won't regret it.