The problem with coalescing around React is that it's not really a framework. The lack of a default Rails-like monolith encourages every dev to assemble their project from a la carte pieces - so every React app has a different project structure, a different data library, a different build tool, etc. Even worse: since everyone wants to build their app "the right way", there's constant churn as new best practices and micro-libs are introduced every couple of months.
I'm really hoping that one of these React dialects will win out soon, as it's not really a "common language" until everything is mutually intelligible.
I'm not an expert in this area, but the impression that I've gotten from the React front is that one of the benefits and reason for traction it isn't a framework as much as a very good way to handle the view layer that's flexible enough to let people take liberties with the rest of their application design...and the way that it handles it works very smoothly with server side rendering as well.
Much like jQuery being able to work with other JS libraries smoothly was a big selling point, React seems to be providing a modular approach that's flexible enough to work with many of the more opinionated options out there without having to dictate everything about the application.
One of the biggest churn points around JS frameworks wanting to do things this way or that way, full single page app or hybrid server side / client side, integrate to existing site or build from scratch.
End of the day, the browser is the view layer. Most of the other frameworks that try to make it significantly more than that are always going to lose when being applied to existing systems or server side heavy systems.
The React approach is basically just simplifying and removing pain points. It's easier for Rails to define some standards on the server and database side because the server side is where the core logic of every application lives. You're not going to try to apply Rails to an existing application, so it doesn't have to worry about fighting that battle. That is a major consideration of client side code, which is why you're seeing more wide spread usage of React. It fits more use cases instead of trying to be Rails in the browser.
React is a UI component framework. The testing-in-isolation and composition you can do with React makes it very productive. It's good for reasoning about the fine details in a UI.
Yeah, it would be good to get a router and couple that with React. React is not a total solution for making a web app, and anyone that picks it up seriously will learn that very quickly.
We need lots more libraries like React that focus on one area of development and do that well rather than all these own-the-world frameworks that have both shiny and awkward parts. I want devs to do their front-end library selections very carefully and build a mosaic that fits together well for their app's particular use cases.
Doesn't seem like it will ever be that way for React to be honest. If you want a JS monolith try Ember. Angular 2 may also be that way since it uses Ember's CLI tool.
I love Ember - and one of the best things about it is its emphasis on convention over configuration. React is the exact opposite. While it's an amazing library, it only makes up one part of a front-end stack, which causes everyone to waste tons of time deciding on what the other parts should be.
A set of sane, accepted defaults would help the community tremendously. Personally, I'm hopeful that that's what React/Redux/Webpack turns out to be.
I'm going to take a leap and assume you've done some Rails work because Ember tends to have a lot of Rails users.
In Rails, there's a default view layer handled by ERB but it can be mixed and matched with HAML, Slim or any other view layer. Likewise, you can use ERB, HAML and Slim outside of Rails entirely.
There are frameworks like Meteor that let you have an interchangeable view layer. There are others that build the entire full stack framework around THEIR view layer.
If Meteor made React the default view layer...that would be a step towards unifying the fronts. One full stack system with a shared layer that can be use inside or outside of that particular framework.
This seems to be what meteor is trying to be. A fullstack. Crossing my fingers. Some devs want to pick and choose. I just want it all decided. Let me get to my app.
Biases come into play even when judging supposedly objective things like technical merit. In a startup environment where every new hire has a huge impact on the outcome of the company, the subconsciously perceived 'safe bet' will always be to favor the person who talks and acts the most like a young Zuckerberg.
Must be a privilege of startups who have an ample amount of applicants to sift through. When you're in an area with a smaller tech industry, you need be a little more flexible to whats available.
Being able to view source is a design goal of WebAssembly, according to [0].
If an organization doesn't want you reading their JS, there are already plenty of tools to make it nearly impossible as-is. Do you really learn anything from reading minified, obfuscated code? At some point you're just reverse engineering, which is obviously still possible with WebAssembly.
'Open source by default' is a problem to be solved at a cultural level, not a technical one.
I think that last sentence is spot on. It's an extension of the American Dream: "those who deserve reward will be rewarded." The problem is that many people also believe its insidious contrapositive: "those who are punished are deserving of punishment." This leads to a constant reinforcement of the status quo.
At what point does it make sense for Google-likes to educate their own workforce, skipping the university model entirely? They've already created a B.A. substitute by sponsoring Udacity's nanodegree programs, and now they're working on the other end of the spectrum with a masters / PhD equivalent.
Assume these companies have an excellent selection process (obviously a big 'if'). Could they pluck bright students straight out of high school, send them to two years of specialized super-accelerated Google School, and have a molded and productive employee come out the other side? They have the resources and the expertise, and there's only so many Stanford grads each year.
A workforce of bootcamp devs sounds unpleasant - but with skyrocketing tuition costs, and ever-increasing demand for 'only the best' talent at these companies, there's probably a point at which it makes economic sense for both employer and employee.
Would it be possible for companies to eventually become accredited?
Or, alternatively, would the preponderance of nanodegree programs and "Google Schools" diminish the value of a traditional degree to the point that accreditation would be unnecessary?
I agree that the increasing investment and quality of alternative higher education models will diminish the role of traditional accreditation agencies to some degree. However, there will always be some need for some third-party oversight to ensure educational institutions are delivering what they advertise.
> At what point does it make sense for Google-likes to educate their own workforce, skipping the university model entirely?
Never. You may be too young to remember this, but it used to be very common for companies to hire employees and then train them to do the jobs the company needed done.
Eventually, companies realized that it was much more cost-effective to foist off the expense of training onto employees themselves (and, indirectly onto taxpayers through federal financial aid) so it's become rare for companies to have any kind of formal training program. They expect potential employees to go heavily into debt training themselves, and then hope to find somebody who is already trained for their exact job role.
Google is no different from other companies in this regard: Training people is expensive, and if they can avoid that expense, they will avoid it.
The professor's attitude that you're talking about is perfectly valid - as is your own (opposite) attitude. The tension is a result of modern universities being dual-purpose.
On one hand, the university is supposed to be a crucible where difficult problems are confronted, hard work is accomplished by making sacrifices, and mature professionals are forged through years of dedicated effort. On the other hand, it's also the students' home and living space for several years, and it should provide the comfortable and low-stress lifestyle that most adults need to be mentally healthy.
Inflated tuition costs and degree commoditization have lead universities to adopt a "customer is always right" attitude, bringing the two purposes directly in contention in an attempt to please everyone.
The solution is probably somewhere in between. There's a place for puppy rooms, and a place for strict educational standards - but the two shouldn't mix.
Memorizing documentation and obscure bash tricks is the last thing a developer should be expected to do.
Even reading the documentation (in its 'raw' form) can sometimes be harmful, because you miss out on the contextual information that a search engine provides. Especially if you're new to a language or domain, it's easy to fall victim to the XY problem [0] - you comb the docs trying to implement your perceived solution, when a simple Google search or Stack Overflow answer would give you the solution you're really looking for in seconds.
If something is important to you, you'll absorb it over time anyways.
I was able to get 20 by obsessively combining small tiles first, but just barely. The biggest problem is the rows that calcify and lock together if you don't actively try and break bonds.
The bonds only form with new tiles emerging from the bottom, so it's best to keep the bottom as clear as possible. Also, the timer will skip ahead to a new row if there are no immediate moves left, so it's best to maximize the number of possible moves.
The best strategy I've found is to build two towers on either edge of the board. One tower is reserved for #1-9, and the other side is reserved for 10-19. I aggressively clear the bottom and break any links, and then I optimize the storage of my towers. There's only enough space for stacks 8 high, however, so sometimes I need to make a third stack in the middle (ideally with 9, 10, and 11). I've gotten as high as 20x8 on iOS this way, but it takes some luck.
Interesting! I converged to (almost) the same strategy (I just frantically keep #1-9 at one end (1 column with overshoot to a seconds or third), and #10-19 at the other and try breaking bonds asap). It got me to my first 20.
I'm really hoping that one of these React dialects will win out soon, as it's not really a "common language" until everything is mutually intelligible.