DragonI

Between the Wires: An interview with Vue.js creator Evan You

I interviewed Evan You, the creator of vuejs.org which is a popular progressive JavaScript framework. Evan works on Vue full time with the…

medium.freecodecamp.org|Vivian Cromwell

I’m creating value for these people, so theoretically if I can somehow collect these values in a financial form, then I should be able to sustain myself.

I thought, would crowdfunding work? I just wanted to try this idea on Patreon. Actually Dan Abramov, the creator of React-Hot-Loader and Redux, also did a small campaign on Patreon before.

Another aspect of it is Patreon rewards. If companies are willing to sponsor us, then I could put their logo up on a sponsor page on vuejs.org. It raises the awareness of the community. Half the Patreon funds are coming from individuals and one of them sponsored $2000 a month. I had no idea if it would work out when I tried it, but it turns out it’s kind of working. I think I made the full-time jump when I had $4000 a month on Patreon, and now it’s grown to over $9800 a month.

My job at Google involved a lot of prototyping in the browser. We had this idea and we wanted to get something tangible as fast as possible. Some of the projects used Angular at that time. 

I figured, what if I could just extract the part that I really liked about Angular and build something really lightweight without all the extra concepts involved? I was also curious as to how its internal implementation worked. I started this experiment just trying to replicate this minimal feature set, like declarative data binding. That was basically how Vue started.

In February 2014, that was how I first released it as an actual project. I put it out on Github and sent a link to Hacker News, and it actually got voted to the front page. It stayed there for a few hours. Later, I wrote an article to share the first week usage data and what I learned.

I think, in terms of all the frameworks out there, Vue is probably the most similar to React, but on a broader sense, among all the frameworks, the term that I coined myself is a progressive framework.

The idea is that Vue is made up of this core which is just data binding and components, similar to React. It solves a very focused, limited set of problems. Compared to React, Vue puts a bit more focus on approachability. Making sure people who know basics such as: HTML, JavaScript, and CSS can pick it up as fast as possible.

“There is not going to be this one true framework that just makes everyone happy. The more important part is, make it better for the people who actually enjoy your framework. Focus on what you believe is the most valuable thing in your framework and just make sure you’re doing a great job, rather than worrying about how you compare to others.”

Google Gives Update On Crawling JavaScript Sites & Progressive Web Apps

John Mueller of Google posted a detailed update on how Google currently handles JavaScript sites (including AJAX) and Progressive Web Apps in their index, crawling, and ranking. He posted this on Goo

www.seroundtable.com

John Mueller of Google posted a detailed update on how Google currently handles JavaScript sites (including AJAX) and Progressive Web Apps in their index, crawling, and ranking. He posted this on Google+ and titled it "An update (March 2016) on the current state & recommendations for JavaScript sites / Progressive Web Apps in Google Search.

I am just bringing it more daylight by referencing it over here:

• Don't cloak to Googlebot. Use "feature detection" & "progressive enhancement" [2] techniques to make your content available to all users. Avoid redirecting to an "unsupported browser" page. Consider using a polyfill or other safe fallback where needed. The features Googlebot currently doesn't support include Service Workers, the Fetch API, Promises, and requestAnimationFrame.
• Use rel=canonical [3] when serving content from multiple URLs is required.
• Avoid the AJAX-Crawling scheme on new sites. Consider migrating old sites that use this scheme soon. Remember to remove "meta fragment" tags when migrating. Don't use a "meta fragment" tag if the "escaped fragment" URL doesn't serve fully rendered content. [4]
• Avoid using "#" in URLs (outside of "#!"). Googlebot rarely indexes URLs with "#" in them. Use "normal" URLs with path/filename/query-parameters instead, consider using the History API for navigation.
• Use Search Console's Fetch and Render tool [5] to test how Googlebot sees your pages. Note that this tool doesn't support "#!" or "#" URLs.
• Ensure that all required resources (including JavaScript files / frameworks, server responses, 3rd-party APIs, etc) aren't blocked by robots.txt. The Fetch and Render tool will list blocked resources discovered. If resources are uncontrollably blocked by robots.txt (e.g., 3rd-party APIs) or otherwise temporarily unavailable, ensure that your client-side code fails gracefully.
• Limit the number of embedded resources, in particular the number of JavaScript files and server responses required to render your page. A high number of required URLs can result in timeouts & rendering without these resources being available (e.g., some JavaScript files might not be loaded). Use reasonable HTTP caching directives.
• Google supports the use of JavaScript to provide titles, description & robots meta tags, structured data, and other meta-data. When using AMP, the AMP HTML page must be static as required by the spec, but the associated web page can be built using JS/PWA techniques. Remember to use a sitemap file with correct "lastmod" dates for signaling changes on your website.
• Finally, keep in mind that other search engines and web services accessing your content might not support JavaScript at all, or might support a different subset.

The Sad State of Web Development

Random thoughts on web development

medium.com|Drew

2015 is when web development went to shit. Web development used to be nice. You could fire up a text editor and start creating JS and CSS files. You can absolutely still do this. That has not changed. So yes, everything I’m about to say can be invalidated by saying that.

The web (specifically the Javascript/Node community) has created some of the most complicated, convoluted, over engineered tools ever conceived.

Node.js/NPM

At times, I think where web development is at this point is some cruel joke played on us by Ryan Dahl. You see, to get into why web development is so terrible, you have to start at Node. 

By definition I was a magpie developer, so undoubtedly I used Node, just as everyone should. At universities they should make every developer write an app with Node.js, deploy it to production, then try to update the dependencies 3 months later. The only downside is we would have zero new developers coming out of computer science programs.

You see the Node.js philosophy is to take the worst fucking language ever designed and put it on the server. Combine that with all the magpies that were using Ruby at the time, and you have the perfect fucking storm. Lets take everything that was great in Ruby and re write it in Javascript, I think was the official motto.

Babel

Now it’s some convoluted mess of plugins that tries to do everything everyone ever wanted, while actually doing nothing out of the box. Sebastian seemed like a nice guy, then goes to Facebook and comes out with Babel 6, then to really shove it in my face, he uses that screaming pile of dump called Phabricator to handle issues.

Maybe all the idle Facebook engineers who created Phabricator can get with the idle Uber engineers who created the branding page, and come up with something that is better.

React

I don’t even know where to start with this project. From what I can tell the background of React is: Facebook couldn’t create a notification indicator on Facebook.com, so they create this over engineered dump pile to solve that problem. Now they can tell you how many unread posts you have while downloading 15 terabytes of Javascript. Once they solved that issue they proceeded to write everything in React. They even built a comment system with it, because you know making an Ajax call and a DOM append is really hard.

That’s right. All you guys using React like it’s the only way to solve every problem ever are using it because Facebook couldn’t build a fucking notification icon.

...

Please guys/girls, just take a step back every now and then. How does rewriting your interface in the latest framework get you to the next customer? Or the next 50 customers. Does it actually make your customers happier?

Don’t fucking build a SPA

Really all I’m saying is don’t build a SPA. A SPA will lock you into a framework that has the shelf life of a hamster dump. When you think you need a SPA, just stop thinking. Just don’t. Your users just don’t fucking care.

...

Hello my name is Drew and I’m a recovering magpie front end developer.

Ember.js, Another year of churn, instability and festering frustrations.

I’ve been using Ember.js for years. Practically since it’s inception. That doesn’t make me smarter or more qualified, it just gives me a little more perspective [I like to think]. My current role is “lead Ember.js engineer” on a ten person product team. That is to say, it’s my job to keep up with changes to Ember.js, helper ensure good practices, file bugs, etc. I’ve also published and maintained a few add-ons. I’ve written this post in part to vent about growing frustrations and in part to see if other developers share some of the same concerns.

medium.com|Frustrated Ember Dev

For a very long time the phrase, “stability without stagnation”, has been uttered by many on the Ember.js core team. It’s really just a cute way of saying, “things are changing, keep up or get left behind”. The churn of Ember.js has become exhausting. More and more I’m fielding questions from other team members about, “Why did this change?”, “How should I do it now?”, “This is different, but how is it any better?” and my personal favorite, “What’s the status of Ember-Data?”. I’ve become an Ember apologist just to mitigate the frustrations of my colleagues, some of whom who have compared Ember’s churn to that of Tapestry 3, 4 and 5.

So let’s talk about their frustrations, and mine.

We do our very best to “color inside the lines” as Tom Dale once put it. We’ve adopted ember-cli, we’ve adopted new APIs, we’ve discontinued the use of old APIs ASAP, and we frequently refactor to newer patterns (e.g. services, components). All of these have a cost to us. A cost to change the code, a cost to continue to educate team members and most importantly a risk of regressions for our users. After each “major” upgrade/refactor/whatever_you_call_it we review the high level net out. All to often the net out is, “We’re up to date on Ember. Things didn’t get easier, they didn’t get harder, they’ve just changed.”.

Let’s get specific about Ember 1.10.x — Ember 2.x.

Recently, we’ve spent a good bit of time cleaning up all of the deprecation warning and trying to practice Ember 2.x patterns. The first and probably most prominent example that comes to mind is {{bind-attr}}. I spent nearly a week of my life changing: `{{bind-attr class=”isActiveUser:enabled:disabled”}}` to `class=”{{if isActiveUser ‘enabled’ ‘disabled’}}”` and the high level net out of this change is as a previously stated, not better or worse, just different. The same can be said for computed property, `{{each}}` block helpers, `this.attrs`, “router resources”, angle-brackets”, the list goes on. It’s not really better, it’s just different.

With Ember, proper code patterns have always been a bit hard to figure out. And if you try to swim upstream, you’ll get burned. The docs and guides cover the API really well, but they don’t cover holistic patterns. There is no definitive authority on how to structure large parts of your code in a way that is future proof, this recent effort was no exception.

Some examples of improvements are:

• LTS (Long-Term Support) Releases (RFC #56), which can give users who want to upgrade less often than every six week a sanctioned way to do so.
• Mandatory docs. No new features will be added to the Ember 2.0 release channel without accompanying documentation.
• More informative deprecations. All deprecations will include which release their behavior will be removed in, as well as a link to transition instructions.
• Improved deprecation tooling. More informative deprecations allow us to make the Ember inspector's deprecation pane smarter, and more useful for incrementally working through deprecations. In particular, we can avoid nagging you (by default) about removals that will not happen until far in the future. For more information see RFC #65 and the included comments.
• Svelte Builds, which allow you to ask Ember CLI not to include deprecated features you are no longer using. This will reduce pressure on future major releases.

A primer for building Single-Page Applications with React.

github.com

This is a work in progress.

At the time of writing, the examples were written for React 0.12.x. This guide will be updated with examples for React 0.13 ES6 classes soon!

...

This primer makes use of several libraries, but it is by no means a "React the right way". It's just a introduction to how I am building my own React applications. The goal of this primer to help developers get familiar with React and dive right in. Maybe you will come up with approaches that work with better for you and I hope that you share them with the community! Or if you're already well versed, help improve this document so others in the community can benefit. Sharing is caring!

Over the past year I conducted performance audits on a handful of sites that all used client-side MVC’s, typically Angular but not always. Each site had their own optimizations that needed to take place to improve performance. Yet a pattern emerged: client-side MVC’s were the major bottleneck for each. It slowed down the initial rendering of the page (particularly on mobile) and it limited our ability to optimize the critical path.

Back in December, The Filament Group analyzed a bunch of client -side MVC frameworks to see their impact on the initial load time of a page. The results to render a simple To-Do app were disappointing:

• Ember: 5s on a Nexus 5, 3G connection
• Angular: 4s on a Nexus 5, 3G connection
• Backbone: 1s on a Nexus 5, 3G connection

I’ve said it before: if your client-side MVC framework does not support server-side rendering, that is a bug. It cripples performance.

It also limits reach and reduces stability. When you rely on client-side templating you create a single point of failure, something so commonly accepted as a bad idea that we’ve all been taught to avoid them even in our day-to-day lives.

“Don’t put all your eggs in one basket.”

It’s pretty good advice in general, and it’s excellent advise when you’re wading through an environment as unpredictable as the web with it’s broad spectrum of browsers, user settings, devices and connectivity.

This might sound like I’m against these tools altogether. I’m not. I love the idea of a RESTful API serving up content that gets consumed by a JavaScript based templating system. I love the performance benefits that can be gained for subsequent page loads. It’s a smart stack of technology. But if that stack doesn’t also consist of a middle layer that generates the data—in full and on the server—for the first page load, then it’s incomplete.

This isn’t idealism. Not only have I seen this on the sites I’ve been involved with, but companies likeTwitter, AirBnB, Wal-Mart and Trulia have all espoused the benefits of server-side rendering. In at least the case of the latter three, they’ve found that they don’t have to necessarily give up those JS-based templating systems that everyone loves. Instead, they’re able to take advantage of what Nicholas Zakas coined “the new web front-end” by introducing a layer of Node.js into their stack and sharing their templates between Node and the client.