Being Azure Functions based on the WebJobs SDK, they provide most of the functionality already available in WebJobs, but with some new cool capabilities.
In terms of triggers, in addition to those already available for WebJobs (e.g. Service Bus, Storage Queues, Storage Blobs, CRON schedules, WebHooks, EventHub, and File Cloud Storage providers), Azure Functions can be triggered as APIs. And HTTP calls don't require kudu credentials but can be authenticated via Azure AD and third-party identity providers.
Are you interested in learning Azure from scratch! Here's the right video for you on Azure provided by Intellipaat:
In regard to outputs, the only difference is that Functions can return a response when called via HTTP.
Both support a wide variety of languages, including: bash (.sh), batch (.bat / .cmd), C#, F#, Node.Js, PHP, PowerShell, and Python.
Being Functions currently in Preview, tooling is still not ideal. But Microsoft is working on it. Hopefully, we get the same flexibility of developing and testing Functions locally as we currently do for WebJobs with Visual Studio.
The most significant and cool advantages brought by Functions is the alternative of having a Dynamic Service Plan with a "Serverless" model, in which we don't need to manage VM instances or scaling; it's all managed for us. Additionally, by not having dedicated instances, we only pay for the resources we actually use.
A more detailed comparison between the two here: https://blog.kloud.com.au/2016/09/14/azure-functions-or-webjobs/