On Friday, 30 October 2015 at 21:03:21 UTC, Brad Anderson wrote:
> On Friday, 30 October 2015 at 16:16:11 UTC, Sebastiaan Koppe
>> I really have to say I fail to see any value in that JS interface generation feature. The idea is nice, but it needs adapters to common ajax libraries, instead of homegrown stuff.
>
> I'm not really a web developer. Do you have any examples of what you mean?

In frontend development people are likely to use the same framework/library they used last time, in order to speed up development. Besides know-how, most of that stuff is battle-tested.

There are lots of quirks with ajax and getting everything right takes time. Take for instance the variety of errors (that nobody seems to check on): bad request, exception on server, cors errors, wrong response type, connection timeout (server down), no internet.

(I live in China and the great firewall leaves a lot of websites in a half working state. There are only a few sites that catch these failures and notify the user, everything else just freezes.)

I personally am a big fan of React and RxJS, so if I do anything with ajax, it's convenient to use ajax extensions for RxJS, since I am using it anyway.

So, given that it takes time to develop your own ajax lib, and people already use frameworks/libraries that have good ajax support, it makes no sense to develop your own.

Instead, what you want to do is generate code that uses one of those libraries. Here is an example of how an ajax call looks like using RxDom, an extension for RxJS:

```
import RxDom from 'rx-dom';

module.exports={
	status: () =>
	{
		return RxDom.DOM.ajax(
		{
			url:"/api/v1/status",
			method:"GET",
			responseType:"json"
		}).pluck('response');
	},
	//....
}
```

On Saturday, 31 October 2015 at 03:07:35 UTC, Sebastiaan Koppe wrote:
> In frontend development people are likely to use the same framework/library they used last time, in order to speed up development. Besides know-how, most of that stuff is battle-tested.
>
> [...]

Very interesting. Thanks for answering.

On Saturday, 31 October 2015 at 07:57:06 UTC, Brad Anderson wrote:
> On Saturday, 31 October 2015 at 03:07:35 UTC, Sebastiaan Koppe wrote:
>> In frontend development people are likely to use the same framework/library they used last time, in order to speed up development. Besides know-how, most of that stuff is battle-tested.
>>
>> [...]
>
> Very interesting. Thanks for answering.

The other thing is that you want to tap into their workflow.

Every frontend developer uses npm and every project starts with tools like grunt or gulp, browserify or webpack, + a dozen others.

What these tools do is support their development - every time they save a file their code gets linted, cross-compiled from es6/7 or coffeescript down to javascript, sourcemaps get created, everything gets concatenated, and sometimes hot loaded into their browser so they don't have to press F5.

For production these tools do similar work but often uglify and apply some cache-busting techniques as well.

For css the tools are similar, but they operate on less or sass files.

This all means that the js interface that gets generated by vibe needs to be integrated into their gulp/grunt workflow, which basically means generation the interface at compile time.

On Saturday, 31 October 2015 at 03:07:35 UTC, Sebastiaan Koppe wrote:
> On Friday, 30 October 2015 at 21:03:21 UTC, Brad Anderson wrote:
>> On Friday, 30 October 2015 at 16:16:11 UTC, Sebastiaan Koppe
>>> I really have to say I fail to see any value in that JS interface generation feature. The idea is nice, but it needs adapters to common ajax libraries, instead of homegrown stuff.
>>
>> I'm not really a web developer. Do you have any examples of what you mean?
>
> In frontend development people are likely to use the same framework/library they used last time, in order to speed up development. Besides know-how, most of that stuff is battle-tested.

Keep in mind that javascript frameworks die after ~2 years.

> Instead, what you want to do is generate code that uses one of those libraries. Here is an example of how an ajax call looks

Browsers are now providing promises/futures for fetching data:

https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch
https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Promise

On Sunday, 1 November 2015 at 19:44:12 UTC, Ola Fosheim Grøstad wrote:
> Keep in mind that javascript frameworks die after ~2 years.

They may die young, but every framework is an improvement upon the last. So in a way the reasoning and principles behind them continue. In that sense it follows the development pattern everything with computers does:

Cool Idea -> Everybody Happy -> It Sucks -> Complete Rewrite

> Browsers are now providing promises/futures for fetching data:
>
> https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch
> https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Promise

Yep, that would be another target. And while it is a nice development, promises and futures don't even come close to the power of RxJS or BaconJS.

https://github.com/Reactive-Extensions/RxJS
http://baconjs.github.io/