51–60 of 60 posts
If Facebook would agree on using standard Typescript, instead of their own thing, that would be amazing.
> There are a lot of JS tools, but none of them do what we want. We’re trying to coordinate them. We want to provide a good default experience out of the box, so we’re building a CLI to: scaffold, skeleton files, set up build, set up testing environment, possibly even deployment Was there something wrong with the yeoman & grunt/gulp combo? The yeoman tool is great for the scaffolding and skeleton story, and even for…
The problem is that a lot of these js tools that are being built are being built on top of other hobbyist js libraries that are built on top of others that creates this weird chain of dependency that appears to arise from nothing other than the author's coding style preference. Take a look at just one of gulp's dependencies (and arguably one of the most important) vinyl-fs which it uses for file watching. This is the…
Earlier quoted context omitted.
In my experience using grunt, gulp and broccoli as task runner / build systems for complex applications, they all end up doing about the same thing. In a way, it makes a lot of sense that broccoli is part of the Ember-CLI system - I found broccoli to be the most opinionated of the runners. As long as your structure mapped easily onto the opinions of broccoli, things were easy and speedy. If you want to do something n…
> In my experience using grunt, gulp and broccoli as task runner / build systems for complex applications, they all end up doing about the same thing. This may be true for a codebase of trivial size. With a sizable codebase and many build steps (defeaturefy, babel, es6 modules, es3recast, jshint, jscs) you quickly see grunt and gulp fall flat. Gulp and Grunt absolutely have a simpler API for blindly chaining tasks. A…
I'd say: I ended up building all the features I wanted in broccoli as part of a gulp build system. It did not "fall flat", rather, at the time (about eight months ago), I found broccoli had fallen flat- it didn't handle what I wanted, and even when it did it was impossible to do incremental rebuilds (say) of files - change one thing and the whole system rebuilt itself leading to a livereload on * rather than a single changed file. On top of everything else, it was dog-slow on medium-to-large codebases. I understand that this has changed since, but the frustration I had originally getting it to do what I want coupled with the length of time it took to run rebuilds (nobody wants 10k msec builds when the same process elsewhere takes 300msec) made me transition to gulp. I'm sure broccoli is just fine nowadays, and my read of the emails (I still am watching the repo) seems to indicate that Stefan ironed out a lot of the performance issues around watching and rebuilding (symlinks on OSX, IIRC, were a dog).
As I said the first time around: you can do just about anything with gulp or grunt, you just have to DIY. If you happen to enjoy spending some time really getting to know your toolchain, they all end up doing about the same thing, and with grunt and gulp it's marginally easier to configure certain aspects of the process.
Fascinating comment from Christopher Chedeau of React: "The end game isn’t ReactNative. We want the web to win. Would be great for Angular to try to implement on top of our same primitives to see if we could share the work." It's as if ReactNative is being treated (strategically) as a more powerful version of PhoneGap.
That is, of course, if the standardized platform had all the capabilities and great UX of the proprietary platforms. This is where the web often falls short, and the companies behind proprietary platforms have some very sweet incentives to keep it that way, i.e. developer lock-in and maintaining complete control over the platform's direction.
Despite all the impediments, I still firmly believe an open platform will triumph eventually, because developers love efficiency, and the current landscape of wasting work on rebuilding for proprietary platforms is anything but efficient.
Fascinating comment from Christopher Chedeau of React: "The end game isn’t ReactNative. We want the web to win. Would be great for Angular to try to implement on top of our same primitives to see if we could share the work." It's as if ReactNative is being treated (strategically) as a more powerful version of PhoneGap.
I don't see why any reasonable developer would choose building the same app on multiple platforms over building it once on a standardized platform and having it just work everywhere. That is, of course, if the standardized platform had all the capabilities and great UX of the proprietary platforms. This is where the web often falls short, and the companies behind proprietary platforms have some very sweet incentives…
Platforms have different characteristics: different input methods, different display sizes, different common use cases, different interface conventions and standards, different conventions for connection to online platforms, ...
If you’re making a self-contained game for iOS and Android (for example) then sure, something identical across platforms is better. In the case of a general “app”, you’ll get a better result if you design the interface from first principles on each platform.
Earlier quoted context omitted.
I don't see why any reasonable developer would choose building the same app on multiple platforms over building it once on a standardized platform and having it just work everywhere. That is, of course, if the standardized platform had all the capabilities and great UX of the proprietary platforms. This is where the web often falls short, and the companies behind proprietary platforms have some very sweet incentives…
> I don't see why any reasonable developer would choose building the same app on multiple platforms over building it once on a standardized platform and having it just work everywhere. Platforms have different characteristics: different input methods, different display sizes, different common use cases, different interface conventions and standards, different conventions for connection to online platforms, ... If you…
I should have been more specific in my original post. I'm not advocating that a smartwatch interface should be built on the codebase as that of the phone interface. Rather that a smartwatch interface for an app on iWatchOS (I'm actually not sure what the official name is) should be built from the same codebase as a smartwatch interface for an app on Android Wear, with platform capability or design convention differences handled on a case by case basis as exceptions rather than the rule, ideally abstracted away by the standardized APIs themselves or frameworks built on top of these APIs (the Ionic Framework is an example of something that does this extremely well for smartphone development that's built on top of open standards).
At the end of the day, user interfaces for hardware of the same form factor generally share more than they differ regardless of what software platform they're on. The fact that code sharing ratio across platforms in the typical native app development process does not reflect this indicates that there's room for improvement.
The web is not ready to completely replace proprietary platforms yet, but I'm willing to bet my career on the hope that eventually, it, or some other standardized platform, will be. I wouldn't want to work as an app developer in a future where this isn't the case anyways.
Earlier quoted context omitted.
In my experience using grunt, gulp and broccoli as task runner / build systems for complex applications, they all end up doing about the same thing. In a way, it makes a lot of sense that broccoli is part of the Ember-CLI system - I found broccoli to be the most opinionated of the runners. As long as your structure mapped easily onto the opinions of broccoli, things were easy and speedy. If you want to do something n…
> In my experience using grunt, gulp and broccoli as task runner / build systems for complex applications, they all end up doing about the same thing. This may be true for a codebase of trivial size. With a sizable codebase and many build steps (defeaturefy, babel, es6 modules, es3recast, jshint, jscs) you quickly see grunt and gulp fall flat. Gulp and Grunt absolutely have a simpler API for blindly chaining tasks. A…
Earlier quoted context omitted.
> In my experience using grunt, gulp and broccoli as task runner / build systems for complex applications, they all end up doing about the same thing. This may be true for a codebase of trivial size. With a sizable codebase and many build steps (defeaturefy, babel, es6 modules, es3recast, jshint, jscs) you quickly see grunt and gulp fall flat. Gulp and Grunt absolutely have a simpler API for blindly chaining tasks. A…
"defeaturefy" is a Googlewhackblatt (only result is this thread). Care to explain what this term means? My curiosity is piqued.
Earlier quoted context omitted.
I don't see why any reasonable developer would choose building the same app on multiple platforms over building it once on a standardized platform and having it just work everywhere. That is, of course, if the standardized platform had all the capabilities and great UX of the proprietary platforms. This is where the web often falls short, and the companies behind proprietary platforms have some very sweet incentives…
> I don't see why any reasonable developer would choose building the same app on multiple platforms over building it once on a standardized platform and having it just work everywhere. Platforms have different characteristics: different input methods, different display sizes, different common use cases, different interface conventions and standards, different conventions for connection to online platforms, ... If you…