171–180 of 195 posts
Earlier quoted context omitted.
Right: fragmented, environment dependent, user learning curve, etc. Web: URL + links
Web: Network always on required (offline apps is a joke), code behind a pay wall, data behind a pay wall, forced upgrades, removal of features without respect for the users, no guarantee of availability
>a url
pick one
I'm looking forward to desktop UIs also being supported by something like this -- e.g. native Windows, GTK+, and Cocoa widgets. Then we'd have a true framework for writing GUI apps that can share most of their code across the whole range of platforms, which would make me literally stand up and start singing right now. Lalalalalalala! If you coupled this with conditional stuff around what kind of form factor you're on…
I honestly believe you will be able to see something like that in the near future as device gapping technologies gain more momentum.
Earlier quoted context omitted.
Om is fast at checking if a component's state has changed because you can do a very fast identity comparison on the persistent hash map holding state, but persistent data structures are not faster than their mutable cousins simply because of immutability. That immutability leads to significantly more objects being allocated, which means to really take advantage of these features in a managed language you need a VM wi…
> That immutability leads to significantly more objects being allocated What about shared immutable data structures?
Earlier quoted context omitted.
I like having opinions. People can disagree with them, of course, as has always been the case.
Look up the definition of the word "opinion" on google or a dictionary. Then look up the word "dogma". Then re-read my comment. Fair? It's not the opinion I'm objected to, it's the way of stating it.
Earlier quoted context omitted.
Web: Network always on required (offline apps is a joke), code behind a pay wall, data behind a pay wall, forced upgrades, removal of features without respect for the users, no guarantee of availability
>3 minute installer with possible malware >a url pick one
>a url with a JavaScript exploit
>a url with a img/css browser buffer overrun
>a url with cross site scripting
I see no difference.
EDIT: Actually I do. I is easier to exploit users that can't wait 3 minutes.
Earlier quoted context omitted.
You're really just complaining about the phrasing of it and saying that it should have been worded in a mealy-mouthed way. That's silly, it's just an expression of an opinion.
This is absurd. Are you serious? The way you express your opinions is enormously important. It could easily be the difference between getting a raise and getting fired. Expressing your opinions in a way makes sense to other people and they take well to is the farthest thing from silly ever, it's like a #1 essential skill for life. On top of that, phrasing informs the message, and in this case I was not just complaini…
The code style really reminds me of ExtJS circa 2.x (not sure what it's like now), which was pretty good at what it set out to do. However, React Native requires compiling down to various different platforms which means having to maintain multiple compatibility layers to continually shift to keep up with the native vendors. You're also pretty much stuck with proprietary distributors as well. Fun. Fun. This does look…
I suspect your perspective is a bit skewed as most companies are building native apps first and only doing a webapp when / if it becomes necessary. Native apps have won the this round and their momentum isn't slowing down. IIRC, Facebook is seeing 78% year over year growth on their mobile app, while desktop usage is declining. Instagram is another huge use-case where the web app is a second-class citizen.
Declarative UI is boss. I know Andy (former UIKit team) was quoted in the intro thread but I'll do it again: >I say with confidence as a former UIKit author: React's model for the UI layer is vastly better than UIKit's. React Native is a huge deal. https://twitter.com/andy_matuschak/status/560511204867575808 If you're averse to React because of JSX, “mixing templates and views” and similar superficial “best practices…
I've been against mixing logic and views for the longest time and I still wouldn't mind if separation would have been introduced, but recently I gave up. Either I'll be unnecessary stubborn and miss this awesome new tech or I'll shovel my opinion aside and do try working with this approach.... or at least until someone else introduces new framework that comes with code separation. It's not the end of the world.
After learning react something conked in my brain. As I rehashed the arguments against logic in views, I realized that they recapitulated FP's arguments against uncontrolled mutable state, just without the nuance. Nothing wrong with purely functional logic/computation itself. And that delineation feels a lot less arbitrary than "logic in views is bad".
To be clear, I'm not arguing you should implement domain logic in your views. That's a dumb strawman.
But the religious fervor that people have against logic in views is absurd. Reexamine why you think logic in views is bad, and I think you'll find the arguments are actually against 1. poor factoring resulting in ridiculously complex views (and hiding logic is a halfass, crappy way to control complexity) or 2. mutable state.
Earlier quoted context omitted.
what's wrong with -webkit-overflow-scrolling: touch? doing scrolling in js is so last year.
You can't build the equivalent of UITableView (which is a very important component in almost any iOS app) without frame-by-frame scroll events.
Earlier quoted context omitted.
I've been against mixing logic and views for the longest time and I still wouldn't mind if separation would have been introduced, but recently I gave up. Either I'll be unnecessary stubborn and miss this awesome new tech or I'll shovel my opinion aside and do try working with this approach.... or at least until someone else introduces new framework that comes with code separation. It's not the end of the world.
Are user triggered events for a view part of the view, or something else? I think this is where such a separation of concerns comes in... a view is more than just how it is rendered, it is also events for the view. There are also child components, and handling these events, or encapsulating them into events to be triggered by a given view. When you think of it this way, it makes sense. From a designer perspective it…
Events happen to be triggered by the view and they affect global state which is then reflected in the view.
This is the separation of concerns you want. Components don't need to know about events beyond triggering the ones they need. Components only worry about rendering state.