kensign

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.

literally hundreds of entries, I don't think that's very cool.

isn't this more about declarative vs. imperative?

photoshop 4, all over again

this makes it official.

:/

I think http://aurelia.io is much cleaner.

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.

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.

It's funny how this anti-pattern like has become so widely accepted.

check out http://aurelia.io

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/

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.

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

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.

yeah... You might want to try it out and read the docs before you make such claims

https://github.com/aurelia/web-components

remember too, the ES6 is transpiled. Also, I am done with the nerd war. If you have questions, use the gitter channel.

that work is handled by Aurelia itself. You don't explicitly need to define the element.

http://aurelia.io/hub.html#/doc/article/aurelia/framework/la...

yes

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.

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.

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

Wow. I am clinging to the past JS development model? I said nothing of technical substance? If you want to develop a large and "simple" application look at Aurelia. The whole point of a web app, large or small is to keep it simple.

What you're misunderstanding is the basic foundations of solid software principles. Popularity does not equal tried and true. That's not logical. I understand React, or else how could I possibly nail it to the wall? You assume I use some sort of JQuery paradigm to develop UI applications, that a pretty presumptive claim on your part and it is absolutely not true.

>Working directly with the DOM means mutating it in-line and your state and you have to become a manual book keeper to make sure your App state and DOM mutations stay in-sync. It's slower, more tedious to maintain, harder to debug and visualize your App's state, etc. There's a reason why the world and all major SPA fx's has moved on from jQuery, you're clinging on to the past JS development model.

No, this is not what it means, this is your opinion. What do you think you're doing when you manage the state of a React component? If you cannot debug your app and understand its and runtime state, you need to look at your complexity bottlenecks. The browser runtime is an event-driven framework. Custom events avoid implicit calls and runtime race conditions.

What I am clinging to is the living standard and a clean separation of concerns in software development. I am standing on the shoulders of giants. I cannot help what choices developers make and what shortcuts they make to understand the browser's inherent technology. I've actually built enterprise SPAs and I have been doing it for the last 16 years, since the DOM was actually introduced.

Decompose React yourself. I've laid out my argument. It's not a rant, it's reality. React may have attractive advantages, but I don't think its adoptees understand the seriousness of the trade-offs they're making.

Well it doesn't simplify development and that's the point, it's not a clean separation of concerns. It defies the whole purpose of using CSS, the DOM API and keeping your javascript's structural patterns cohesive. This is why Webcomponents are now part of the living standard. The browser runtime nullifies whatever React was trying to achieve.

Do you actually understand how it really works?

Yeah this is perfect timing for us too, we go wide release in the next few months. It's so great to write ES6 and create a modular system. Our product is based on DDD and BDD, so we are able to take full advantage of a rich domain model with services and keep our view-models as light as they need to be. We also take heavy advantage of web components reuse and application events. There is still a lot of refactoring to do as Aurelia is coming into its own, but it is hands down the best dev platform for web apps I have ever seen. Angular2 is DOA and React is the ugliest anti-pattern to plague the web. Thank you to all the Aurelia community for baking this baby.

That's a very good point. Aurelia is a system. It gives you what you need to build an application as software. I think many developers realize that they don't need to learn how to use structural patterns, but they do need basic functionality, such as binding, and it needs to be invisible.

We've done amazing things with Aurelia. More and more, it's beginning to feel like an extension of HTTP wired directly into the UI. I'd like to think that it will become The Next Big Thing, but it will probably stay relegated to a lesser seen community of devs like those of the Django community. Architects, engineers and developers will love it while many may not realize just how beneficial an agnostic system really is.

Aurelia is an amazing leap forward for standards-based development. React is a horrible anti-pattern, Angular 2 has no basis in standards and is so complex, it's not a useful development platform. I've been using Aurelia for 18 months and it has only evolved to be more and more useful and powerful for SPA. I am merely an advocate and not an evangelist, but you owe it to yourself to give it a trade-off analysis. Please think carefully about web components, ES6, and web standards before you leap into technologies that are way off the path.

complete garbage.

UUIDs as tokens? wow.

use a ttl on like a cache store, such as redis

And not to mention how difficult it would be to apply Oracle's logic to the innumerable applications that have modified a java version for their own use. I know this is argued in other posts on this thread, but just how in the world can Oracle justify FOSS and its implementation thereof a violation of copyright in these cases as well?