I mean if I look at the GitHub stars it seems pretty hyped to me. (It's between Angular/React and Ember)
I mean if I look at the GitHub stars it seems pretty hyped to me. (It's between Angular/React and Ember)
Similar to Crystal, Vue has looked at the other frameworks and adopted the good parts from them. I personally don't think the hype is anything but a result of hard work and a genuinely good framework.
You probably want to give it a bit more time. It takes 1 or 2 years after a js framework goes mainstream for the disillusionment and disappointment to set in. We are still in the Vue.js honeymoon phase.
The unfortunate part is that it's moments like this (when a framework makes it into the spotlight in a big way like this) that those hordes begin their swim.
Evan is an excellent developer, and it won't by through his volition that Vue gets ruined.
1. Framework X is created based on the vision of its founder
2. Lots of people begin to use it
3. X gets better and better (user feedback + excitement of the project's success)
4. X becomes super popular and attracts people from other frameworks
5. More and more contributors begin committing code (helpful, but hard to manage beyond a certain volume), and entropy increases - more bugs start getting through (think Rails, where there were loads of security and data loss bugs in the span of single years)
6. People bring their ideas with them, which is helpful at times, but which also begins to dilute the X creator's vision and replace it with a democratic vision (sometimes good, sometimes bad)
7. Social pressure causes the creator of X to begin changing his vision to accommodate the community
The apex of quality is at # 4, and that's the point we're approaching now. Also worth noting is that this timeline isn't always followed exactly. Take Django, for instance. It was able to keep up with community demands without caving in to too many wild requests, and it managed entropy by keeping the number of core committers to a minimum for many years.
With some projects, it's both obvious and simple. Similar to eternal summer. Democracy means that all of us get to be dumber than any of us.
Once the new framework gains popularity the limitations caused by ignoring complexity start to surface and so the framework has to add features to handle them, creating complexity of its own.
Then the cycle repeats itself.
As far as I know, all major search engines are evaluating JavaScript client-side and index the resulting html, only a chinese one had problems with SPAs.
There was even a site from Google, where you could enter a URL and see how Google sees the page.
Here's a website that's an SPA https://preactjs.com
I don't have an exact page count, but I was able to find 15 pages from browsing around.
Here's how many pages various search engines have indexed using the query "site:preactjs.com"
Google: 17 Bing: 6 Yahoo: 6 Baidu: 1
One of the Google results is an error page, but it presumably can't be de-indexed automatically due to there not yet being a way of declaring a 404-equivalent in SPAs.
I've also read (I can't recall where) that Google has a latency of a few days when it comes to indexing SPAs compared to server-rendered apps. This may not be a problem for you, but it's worth knowing about.
I think Jason Miller, the Preact developer, re-tweetet the article about SEO & SPAs a few days ago.
But, because of progressive enhancement, I would using SSR on my next project anyways.
But there are public websites with a high degree of interactivity (such as social networks, or ecommerce sites) for which SEO is a huge concern.
Yeah there's a lot of FUD about how google indexer works, needlessly IMO