fleshweasel

Ask Apple, who hide it from you in Xcode and riddle it with human-unreadable generated IDs and noise elements, in addition to needless reshuffling of elements after editing which overcomplicate your diffs and obscure the meaning of changes. Interface Builder in all its forms is indefensibly bad in execution.

Idempotency is a good example of a trivia term that would be unreasonable to expect most recent CS graduates to know. Not to say that it's not a valuable property for a service or library or whatever to have under certain circumstances-- but it's not a reasonable way to decide whether a candidate for a junior position is a good fit.

I'm a little confused as it looks like an image in the article labels a string literal as being a comment. Am I misunderstanding something?

so..not Go :P

They're promoting this as a new dev environment for .NET Core, but there's still ZERO tooling for Razor. I tried starting a simple example project and the .cshtml files didn't even have any syntax highlighting, let alone syntax/type checking.

I don't know how you work on cross-platform ASP.NET for this long and still not have the tooling for your templating engine ported.

It seems like the "ASCII puke" concrete syntax for regex patterns doesn't scale that well. Regular expressions have binary operators, parenthesization, named groups, lookaheads, etc.-- if you're building a sophisticated regex of more than 10 characters or so, why not have some kind of an object model for this stuff so you can have reasonable forms of composition, naming of intermediate values in construction of a larger pattern, and the ability to attach modifiers to things without needing to pack more @#$%&*!^ un-Googleable junk into string literals?

I don't see why there can't be React-like libraries written and used in languages that compile to native. I'm not expecting to have JSX but I should be able to write component classes and implement their render methods, returning view trees written with some kind of object/array literal syntax.

To get as good of a development experience as React, it would require some work by the compiler and runtime people to basically let you do something like hot loading--Android has something like this now, and maybe Apple will get it too, though I'm not holding my breath.

I think it's a no-brainer for web development these days to do React because 1. you can opt out of it for parts of the page it's not going to work with for whatever reason and 2. the performance is pretty damn good compared to lots of alternatives, including writing all the UI state management logic yourself. However, I've not been convinced that the buy-in is worth it for native mobile development. Can someone who knows more tell me: is it fairly easy to do something like say "I can't/don't want to use React Native for this view controller--I'm going to implement it in code and use it and everything will just work."

I'm pretty sure this is why the Apple online store needs to be taken down for them to add new products.

Do you mean Visual Studio?

The file changing just from being looked at is one of the basic reasons that IB is bad. Apple made a grievous mistake in designing UI markup that is intended to be hidden from developers. Un-organizable, un-diffable toxic sludge.

It's absurd to have to beg the wealthiest software company in the world for what should be considered really basic stuff. Xcode is consistently unstable, slow, missing simple essential functionality (like refactoring), and Apple's interface builder is something that most experienced Apple devs know to run for the hills from.

Every tool for its job. If you have serious dynamic behavior and you try to handroll it yourself, you risk either low maintainability and bugs in your bespoken optimized DOM manipulation algorithm or doing things in fundamentally inefficient ways. That said, people should be cautious about taking on new dependencies, and definitely need to take an evidence-based approach to performance optimization.

Haven't had the chance to try it myself but I have read quite a bit and I like what I see, particularly the high quality error messages in the compiler. However, I think I'd have a hard time getting my team on board with it as we use Visual Studio for the bulk of our development, and we would need to learn to work with the JavaScript interop APIs to do things like try Elm out for a single new feature on a page.

I know what you mean with regard to event handlers being passed down to children and children of children and so on and the complexity that can bring. I haven't used redux, but I understand it as being an attempt to simplify that kind of problem.

I haven't written any higher order components myself, unless you consider parameterizing event handlers in props to be higher order.

One of the biggest reasons I favor React is that it's much easier to add a templating language to a programming language (i.e. JSX) than the other way around. Every construct for making decisions based on your data, traversing your data, etc. is more cumbersome and harder to validate in handlebars or whatever identical looking templating language the community came up with this week.

I also am strongly against string references to model properties in your template. Again, it's much better to use tools that provide some static validation of what you're doing.

Give me React with TypeScript to help me make sure I'm passing around what I said I'm expecting to receive at each point as features are changed and added, and I'll be in business.

Honestly, I use React in spite of my opinion of Facebook.