ben336

So there seem to be 2 separate issues this post is addressing.

1. A lot of JavaScript frameworks are being released 2. JavaScript frameworks are being updated too fast.

His biggest example, the Angular 2.0 split, is of the second one, but he seems primarily concerned with the first one.

I can see the first one being a problem primarily for developers keeping their skills up to date. The fact is that once you've put a decent amount of code down into an application, you're not going to be constantly switching frameworks. Maybe do it once, but otherwise the applications that are already built will stay on a stable foundation. So for developers working on a single or stable set of applications (not client work), this shouldn't effect their actual work. There may be an issue of skill decay if employers are constantly looking for the latest and greatest, but outside the Silicon valley bubble, I still see a lot more jQuery and Backbone job postings than Ember or React.

As for the issue of frameworks lacking stability, I frankly don't see that. Yes Angular is making big breaking changes. But otherwise? Let's look at the other 6 biggest front end libraries/frameworks.

jQuery has been fairly stable for a few years now, with minimal breaking changes.

Underscore has been very stable, albeit growing with competition/help from Lo-Dash

Knockout and Backbone have evolved slowly while remaining small and very small respectively.

Ember has a very clear process for moving their framework while allowing actively developed applications to stay up to date in a reasonable way.

React is still pre 1.0 and that's something you should know going in.

Basically if you started a project with any of those technologies (or angular for that matter) at some point in the past 3 years, you've probably had a pretty easy time in adjusting as the library specific concepts have changed.

I just don't see the idea of "Frameworks are evolving too quickly" as being particularly compelling. There's a lot of information out there. Yes if you want to know it all and always be using the newest shiny thing, it will probably be too much. But none of this is preventing anyone from actually building useful things today.

Not all "first-party" but Vim has a very very rich set of search and file management features:

http://benmccormick.org/2014/11/10/vim-workflows-file-switch...

I worry when people brush aside ethics concerns without deep concern about the consequences. I'm not arguing for or against arbitration, I'm not well enough informed. I'm arguing against claiming you have to take an action you believe to be unethical simply because of the gain involved.

I'm always worried when I see sentences with the structure "It's hard to justify [doing/not doing] X even if it's [unethical/illegal]". What type of justification do you need?

Thats basically what they described isn't it? This compliance export feature is the only thing that allows reading private messages, and it is disabled by default and requires significant hoop-jumping to enable. So for most companies the original privacy policy will apply effectively.

This is a nice start towards something that might be useful. A few thoughts about stating that "101 will be maintained to minimize overlap with vanilla JS." though:

1. Lo-Dash and Underscore overlap with ES5 for a few reasons. First, it allows them to support environments where ES5 functions aren't available. Those are becoming less common but still exist. But the other big reason they overlap is that Underscore and Lo-Dash both outperform native functional methods by a significant amount. Unintuitive but true, see my comparison from a few weeks ago [0]

2. It's worth thinking about who this library is for. The support for common JS and highly modular nature of the library make it seem like it is focused on Node first. But the value in a smaller library becomes much more clear in the browser where page weight matters.

These aren't meant as criticisms, it's good to see new ideas. But it's worth thinking about what niche you're filling when you develop a library like this.

[0]: http://benmccormick.org/2014/11/12/underscore-vs-lodash/

They make their money off the hardware though. And plenty of people use Apple hardware without using Apple services. I have an iPhone/iPad/Mac, and don't use Apple services for email/document/storage/photo backup etc. I appreciate their OS software and hardware, but for the most part think there are better options for pretty much all of their services.

> How big is the "full" set of polyfills anyway?

Google's polyfills for custom elements that they ship with Polymer weigh in at around ~151Kb of JavaScript, around 10x the size of a small library like Underscore, and 4-5x times the size of an MVC framework like Angular. And they only cover about 5-6 specs (the 4 webcomponent specs and a few more to support them) Those are admittedly hard to polyfill features that will be bigger than most, but it turns out that polyfilling "everything" is hard and would add significant page weight.

Agreed, feature detecting afterwards makes sense. Others seem to be suggesting feature detecting before requesting the polyfill script.

Quick and simple meaning... are you checking for every feature back to ES3?

The point of this service is that its not requiring the user to know what feature to look for. They'll polyfill anything thats needed. To do feature detection to the level they're trying to serve you'd have to check EVERY API that needs polyfilled on an in-use browser. Full feature detection also involves looking for apis that exist but don't follow the spec. Checking every single API possible on every browser would not be quick and simple. User agents allow them to settle on a list of known needed polyfills without any code needed for the user beyond a simple script tag.

There are definitely tradeoffs to their approach but I can't say "I don't see any reason" why you wouldn't feature detect for this.

You can't use feature detection with a simple script tag. It's calling in a script and the cdn chooses the file to send based on the user-agent. No Javascript is run that would allow it to feature detect before choosing to send the load. There may be feature detection afterwards of course.

I think people who are doing nothing right now, or have their own ad-hoc organization scheme using email will love Inbox. People who have a more disciplined system for calendar/todos/emails will not want to use the reminder/pinning features. But I still found it nicer than traditional Gmail for quick triaging.

Windsor Circle http://www.windsorcircle.com/ - Durham NC

Front End Developer & Python Developer

=====================================

We're hiring developers on the front end and backend to join our funded startup (we recently closed a $6.25M Series B) to help us build and expand our market leading Retention Automation Platform.

Backend Developers will have an opportunity to work with Python, the Pyramid web framework, and and many of the leading ecommerce and marketing platforms in the world. Front End Developers will be able to work in JavaScript with Backbone, jQuery and MarionetteJS to build out our rapidly growing web application.

This is an exciting opportunity to get in on the ground floor with salary and stock options while working with cutting edge technology. Telecommuting is available 1-2 days/wk with the rest of your time spent in our awesome downtown Durham office.

More info here:

http://www.windsorcircle.com/jobs#SoftwareDeveloperPython

http://www.windsorcircle.com/jobs#FrontEndDeveloper

Twitter is the best real time news source I've ever seen. Any discussion of it's utility that ignores that is missing how a huge percentage of its users actually interact with it.

Yes its bad for conversations. Yes it is poor at building communities. But if you want to know whats happening in <insert area of interest here> Twitter can be a fantastic resource. Especially (but not exclusively) if your area of interest involves sports, tech, or politics.

They just became available recently.

Note that Tapbots still hasn't been able to produce a Tweetbot 3 version for iPad, presumably because of the work required to switch the visuals when iOS8 made their aesthetic feel more out of date.

Windsor Circle http://www.windsorcircle.com/ - Durham NC

Front End Developer & Python Developer

=====================================

We're hiring developers on the front end and backend to join our funded startup (we recently closed a $6.25M Series B) to help us build and expand our market leading Retention Automation Platform.

Backend Developers will have an opportunity to work with Python, the Pyramid web framework, and and many of the leading ecommerce and marketing platforms in the world.

Front End Developers will be able to work in JavaScript with Backbone, jQuery and MarionetteJS to build out our rapidly growing web application.

This is an exciting opportunity to get in on the ground floor with salary and stock options while working with cutting edge technology. Telecommuting is available 1-2 days/wk with the rest of your time spent in our awesome downtown Durham office.

More info here:

http://www.windsorcircle.com/jobs#SoftwareDeveloperPython

http://www.windsorcircle.com/jobs#FrontEndDeveloper

"From the beginning" in this case going back to the mid 90s. Pretty sure "Modern template systems" have mostly been written since then.

I've really enjoyed Marionette as a more (but still not very) opinionated approach to Backbone development. You mentioned the messenger protocols, definitely checkout Backbone.Radio [1], it's being created to replace Wreqr, the current event implementation and has a much cleaner API. The plans seem to be to bundle it with Marionette 3.0 when it gets there, but its usable with the current version.

[1]: https://github.com/marionettejs/backbone.radio

I think the phrase "lines of code" is missing in there somewhere :)

actually he worked for Twitter :) 2 different people under discussion here.

Windsor Circle http://www.windsorcircle.com/ - Durham NC Front End Developer & Python Developer =======================================

We're hiring developers on the front end and backend to join our funded startup to help us build and expand our market leading Retention Automation Platform. Backend Developers will have an opportunity to work with Python, the pyramid web framework, and and many of the leading ecommerce and marketing platforms in the world. Front End Developers will be able to work in JavaScript with Backbone, jQuery and Marionette.JS to build out our rapidly growing web application. This is an exciting opportunity to get in on the ground floor with salary and stock options while working with cutting edge technology. Telecommuting is available 1-2 days/wk with the rest of your time spent in our awesome downtown Durham office.

More info here:

http://www.windsorcircle.com/jobs#SoftwareDeveloperPython http://www.windsorcircle.com/jobs#FrontEndDeveloper

looked at pouet.net. Not sure what I'm supposed to be seeing?

the dev releases are hidden on the website. You have to look to find them. The website by default directs you to the very stable 2 version. If you look you can find the stable 3 builds. If you dig deeper you can find the dev builds. Each of these things is clearly labeled and not mixed. Nobody going through the website is going to download a dev build on accident.

It is new on Windows.

> If you don't understand how to use sharp tools, you may hurt yourself and others.

It's still bad API design when naively handling an error case kills everything. Is there an inherent reason that the error value for a pid has to be the same as the "all pids" value? Unless there's a very compelling reason, it seems like very poor design, well documented or not.

This looks like an awesome release from the Knockout Team. I'm excited to play around with their components solution.

Windsor Circle http://www.windsorcircle.com/ - Durham North Carolina

Front End Developer & Python Developer

=======================================

We're hiring developers on the front end and backend to join our funded startup to help us build and expand our market leading Retention Automation Platform. Backend Developers will have an opportunity to work with Python, the pyramid web framework, and and many of the leading ecommerce and marketing platforms in the world. Front End Developers will be able to work in JavaScript with Backbone, jQuery and Marionette.JS to build out our rapidly growing web application.

This is an exciting opportunity to get in on the ground floor with salary and stock options while working with cutting edge technology. Telecommuting is available 1-2 days/wk with the rest of your time spent in our awesome downtown Durham, NC office.

More info here:

http://www.windsorcircle.com/jobs#SoftwareDeveloperPython http://www.windsorcircle.com/jobs#FrontEndDeveloper

the bot doesn't do "who wants to be hired", thats a community effort.

Do you ask everyone you meet on the internet if they've thought about donating some of their income to charity? He's a security researcher, this is a part of how they make a living.