React and Angular Meeting(docs.google.com) |
React and Angular Meeting(docs.google.com) |
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.
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.
Needless to say I got the message. Don't step on their toes! During the React Native launch video they said, basically, "the web doesn't work for native".
Anyway, I'll continue to port the cool stuff from Native back to Reapp. I don't hold anything against them, in fact it's nice to hear they are actively pursuing bringing stuff from Native back to the web. I look forward to seeing what comes of this.
I don't think this was intentional, and I'm sorry if it came off that way. We've certainly pointed people interested in building mobile apps at TouchstoneJS and I'll point people at Reapp too now that I know about it – obviously React Native isn't appropriate in all situations. Will try to keep an eye out and retweet some stuff of yours in the future.
Not trying to just back them for no reason, but I'm happy with what they are giving the community.
> It's as if ReactNative is being treated (strategically) as a more powerful version of PhoneGap.
ReactNative is like Titanium/Alloy. It uses native components to render views, not the DOM. So it has nothing to do with Phonegap except for the use of javascript.
I believe the original poster was referring to the fact that Cordova's whole purpose is to be a testing ground for new browser APIs - and that the goal of the project is to basically become irrelevant at a later point because browser vendors hopefully will have implemented similar APIs.
Sort of like a testing ground for web standards.
But yes, in a technical sense React Native is closer akin to Titanium than Cordova/PhoneGap in its current state.
Angular seems to be a framework devoted to wrangling state. React eliminates state.
I think you meant either
1. the use of HTML for the former and JSX for the later
2. the use of TypeScript for the former and Flow for the later (this isn't true, can use either one with either framework)
With their current API, we can't use the code written for RN on the web.
We actually designed React Native to work on the web. The layout and styles are a strict subset of CSS, the base component such as <View>, <Text> and <Image> can be easily implemented on-top of <div>, <span> and <img>. The gesture system is written in pure JavaScript as a React event plugin and should work as well.
It's just that it hasn't been a priority so far to exercise this possibility. But, every once in a while we make some example runs on the web. For example, two days ago during a hackathon we made 2048 example run (and work) in the browser by modifying less that 10 files.
> The end game isn’t ReactNative. We want the web to win.
Even though I was one of the few people that started React Native, I --really-- did not want it to exist in the first place. But, the sad truth is that you cannot build high quality, gesture heavy, apps on mobile web today :(
Was there something wrong with the yeoman & grunt/gulp combo? The yeoman tool is great for the scaffolding and skeleton story, and even for setting up your build, test, deployment environments using whatever combination of grunt & gulp you want to build into your generator.
I'm starting to get weary of this constant need to reinvent the incredible tools that we have already instead of iterating and improving them.
I love that they're talking with the Ember guys too, as their approach to a CLI seems to be one of reusing other people's work and just wrapping it. There have been too many cases of wheel reinvention, and I'm particularly glad to see that no-one's talking about yet another package manager.
> so folks can declare dependencies like for JSX transpilation
This is an interesting one. It'd certainly solve a lot of the toolchain headache for front-end development.
It's good to see discussion on animation as it seems to have been a long-term headache for React, at least.
I'm not 100% convinced by the Web Worker talk - I think the complexity could mean it's not worthwhile. But it's good to see people unifying their thoughts in order to test it once and for all.
All in all, great stuff. It'd be interesting to see if this could be regularised into some kind of "steering group" for the front-end...
2) The options on Binding- one way, two way, etc
3) Element lifecycle events- HTML custom elements are a small step, but still missing so many
4) Extensible layout model.
5) Control Templates- shadow DOM is an attempt to do this, but is sub-par. Particularly in how styles and events are handled.
Are you saying you "got" what a project like angular that has more than 1000 contributors "didn't get"?
> The template needs to be simple (since designers also have to edit it), and the intelligence should be in code.
Designers shouldn't touch the code. Designers should stick with design. It's your role as a developer to do design integration. At best designers should only deal with CSS and HTML, they should never see a template tag nor be responsible for placing them inside html files.
That would save everybody time. Imagine google, facebook and microsoft agreeing on that, and i think it wouldn't take more than 6 months to see it working in chrome, internet explorer and all the other major browsers would follow.
With the new microsoft, and now facebook and google talking to each others, this is the first time something like this could actually become a reality.
There are things Flow gets right compared to TypeScript. For instance requiring to check the nullness when using the question mark type e.g. `SomeType?`.
I am so happy to see how much effort and consideration that everyone is putting in towards React and Angular as a Modern Web App Framework standard*
* - Standard for Client Side Web Frameworks
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 actual chain of abstractions for the file watching functionality in gulp.
vinyl-fs < glob-watcher < gaze < graceful-fs
* gulp.watch uses vfs.watch provided by vinyl-fs
* vfs.watch is actually just glob-watcher (lol)
* glob-watcher is a simple 20 line wrapper around gaze watch
* gaze uses graceful-fs to watch full paths
Here's the actual description of the gaze library "A globbing fs.watch wrapper built from the best parts of other fine watch libs."
Yet apparently that wasn't enough as the gulp authors had to toss in 2 more layers on top of it. And at the end of the day gulp still sucks for watching files on linux.
I understand that there are other pieces of vfs that are being used by gulp...but it still doesn't make any sense to me how there can be SOOO many accepted libraries dealing with just file watching. And instead of making a pull request for new features on existing libraries, developers are just building other libraries around them to do what they want.
There's so much fragmentation in the JS world and no one can seem to ever agree to work together on anything. In comparison, in the Python world there's pretty much one agreed upon library for something like file watching "watchdog". There are alternatives but it stands out above all the rest.
Broccoli (https://github.com/broccolijs/broccoli), the build tool written by Jo Liss and supported by the Ember community, is truly an asset pipeline tool. It is concerned with transformations to filesystems and file contents, not tasks.
This makes Broccoli a faster and easier to use tool for implementing complex asset pipelines. The main domain object is "trees". A tree represents a directory hierarchy of files that will be regenerated on each build. Broccoli uses directories of symlinks in tmp/ to cache un-changed files from step to step, allowing it to restart a build at any depth and only process those files that change.
Some links you might enjoy on Broccoli:
* http://aexmachina.info/intro-to-broccoli/
* http://moduscreate.com/better-builds-begin-with-broccoli/
* http://hashrocket.com/blog/posts/broccoli-the-build-tool-not... (how Broccoli is used in Ember-CLI)
I can't speak to the weariness, but I can say that Broccoli is completely unlike Grunt, Gulp, or Yeoman and without it (or something like it) Ember-CLI and the next generation of build tools would be impossible. Broccoli has been in development since fall of 2013, and been used aggressively by Ember-CLI users since summer 2014. Give it a look!
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 not supported, or customize how things work, not so much. As an example, I submitted a PR to configure where and how broccoli stores its temp directory structure a year ago (./tmp wasn't right for my project), which is still open (and admittedly wasn't the most elegant solution).
Gulp and Grunt, on the other hand, make far fewer assumptions, provide very little in the way of out-of-the-box "just works", and are far more easy to tweak. In my own experience, my issue was getting certain cat/minify/sort processes to work in broccoli (to deal with angular module declaration ordering) was annoyingly complex enough that I just moved to gulp where it was easier (and someone else had already written a gulp plugin).
Sounds like they're doing exactly that!
I love React and their team, and am incredibly positive on the future of what FB is doing.
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.
We really do care about the web, and before very long we will be able to build great apps for web and on native, with a lot of code re-use. (And if you're willing to hack it, then you can do that today!)
I actually had a really interesting conversation with Bert Belder about some of the lower level problem with file watching. It came up that perhaps there could be a working group around fixing this issue.
Sorry but that's a BS argument if I ever saw one. It's basically an arguemtn from authority and/or popularity.
Something could have 100000 contributors and still be crap and they could still "not get" that it's crap.
JavaEE circa 2002-5 had all the enterprise world using it, tons of aftermarket companies, the best people at SUN and more. And yet, it was utter crap, and a few years later everybody admitted it and were ashamed to be associated with it.
Or take PHP. I'm not against it, but it has tons of contributors (tens of thousands if we count the whole core ecosystem) and it's widely considered a "fractal of bad design".
I agree designers shouldn't touch code (i.e., javascript). But designers should be able to directly edit the visual aspects (i.e., templates). This was one of the goals of XAML.
Angular has a lot of strong & smart contributors. Angular also grew more organically, and broke a lot of new ground. That says nothing about what contributors got/did not get. To equate the two requires a false assumption.
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. And they have the ability (as task runners) to define multiple tasks and compose them.
Broccoli is tricky to learn. In Ember-CLI we go out of our way to make it invisible to devs who shouldn't need to care what tool is running the internals. For the internals however, it is definitely the correct tool.
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.
