kensign's comments

kensign | 7 years ago | on: Facebook's Zuckerberg Preaches Privacy, but Evidence Is Elusive

This is analogous to Google declaring one fine day that its getting out the advertising business, but adding security features to do so. MZ describes steps to improve security and retooling history features to have less immortality and permanence, but people already share facebook posts and profiles as images, not only as stateful markup. People will continue to expose each other and there's essentially no way Facebook can guarantee privacy in that regard. Limiting partner access to user data will ultimately be a trade-off of what they can afford to lose and that's not a commitment to privacy either.

His proposed strategy doesn't really makes sense and seems like misdirection and lip-service. You can't change the way people use Facebook, but you can forgo any pretense of privacy, which may be the only thing that can honestly and realistically be done.

kensign | 9 years ago | on: Do you really want a single-page application framework?

I suggest people check out http://aurelia.io

Otherwise I have to say this is the worst advice for any engineer building a commercial website. Maybe if someone went back in time 10 years, this might look like a solution, but there is a reason all of this is left behind. I've been a web developer for 20 years now and browser development has finally graduated to real software engineering.

The author has a laundry list of grievances based on their own experiences. It's clear that these are merely opinions though, and they can be taken at face value.

"Frameworks and complexity === insanely long cycle times"

This is simply not true and it's purely subjective. Any developer using Continuous Development can roll out changes to production in a matter of hours, if not a few days. Sophisticated apps need to be modular and engineered for a simple workflow, automated testing and a clear separation of concerns. There is no point to setting yourself up for defeat, and if anyone followed this advice, that's exactly what would happen.

There's a clear distinction between the FUD of naysayers compared to people with more sophisticated levels of development experience. I am not sure someone with this mindset could even get past a phone screen. egad.

kensign | 9 years ago | on: Visual Studio for Mac

That's quite an exaggerated presumption. Office for mac has been around for years. VSC will more than likely give sublime a run for its money as they are very similar on the Mac platform. Just because microsoft ports VS, it doesn't reveal anything other than giving developers that prefer Macs another IDE choice. You can get a MBP without function keys and just because Apple has decided evolve their approach to the keyboard, it doesn't mean anything beyond that. It's very interesting that this has become such a hot topic in the dev community. Apple isn't abandoning devs, pure and simple.

kensign | 9 years ago | on: SVG has more potential

SVG is an untapped technology. It functions as an embedded document. When used within the Object tag, it can run javascript and CSS and ideally renders complex graphics with a much smaller payload. Also, they look amazing on all devices as they use the browser's rendering pipeline. SVG has been a fully supported standard for years.

https://sarasoueidan.com/blog/art-directing-svg-object/

kensign | 9 years ago | on: Angular 2 Final Released

Before you consider Angular 2, do yourself a favor and check out http://aurelia.io.

Compare the differences and consider the trade offs with complexity vs simplicity. It's worth a consideration.

kensign | 9 years ago | on: I am a fast webpage

pretty much every standard browser that is in use supports SVG. I've been using it for years.

kensign | 9 years ago | on: Stepping down as Nodevember organizer

The good choice is not to make a hasty decision without the backing of the rest of the organizers. This is not a mistake, it is a very intentional move to exclude the rest of the org.

kensign | 9 years ago | on: React Fiber Architecture

You mean besides the one where I learned it and realized I would never use it in production? No, and here is why:

1. There is no adherence to the living standard

2. Web components are meant for this exact purpose

3. The added complexity and burden on the browser runtime will only create headaches as the application begins to scale.

4. There is no clean separation of concerns.

5. Writing HTML in js files is an anti-pattern.

6. The browser runtime, CSS and DOM obviate what React is trying to accomplish, especially with web components being added to the living standard.

7. Browser networking, workers and server-side events are much more powerful ways to scale complexity.

8. CSS3 is not hard to understand.

9. There is no way to bypass the browser's rendering engine.

10. The business scenarios for our software product did not align with the use of React after a very thorough ATAM.

11. Much better technologies exist that do not cross-cut concerns the way React does. Aurelia is what I ultimately recommended because it did not violate points 1-10.

React isn't pragmatic and if anything, the lack of examination of its internals distinctly reflects the zealotry of arguments that oppose reasonable points. Every dissenting argument I have ever encountered, especially the ones on this thread are rationalizations and opinions. I haven't seen one technical advantage that solid software engineering, the browser API, and HTTP do not already provide.

Discussions like this are meant to become arguments based on facts, zealous or not. As always, fact trumps opinion.

kensign | 9 years ago | on: React Fiber Architecture

lol dude, you're a riot. Have a discussion. How far you want to drift away from the issues that have been laid it is not a discussion. Everything you write is just one big red-herring and the proof of that is laid out right on this thread.

kensign | 9 years ago | on: React Fiber Architecture

thank you, thank you, thank you. Aurelia is an excellent system for this exact use of a web component.
page 1