kalcode

Feel like diamonds are such a great example for the 'a free-market' people. They typically argue that in a truly free-market everything is better.

Well diamond trade exists largely in a free market until it hits some of the countries they sell in but before that we basically have blood being spilt over them and companies existing outside of strong regulated countries to funnel the diamonds into and control the price.

A truly free-market seems very scary in a modern world.

Wouldn't that result in even more lost in transmission?

>They destroy them for brand protection. See this comment:

Comment has some sound reasoning why they feel that way.

Curious though, why do you post/take that commen on a forum that was copied from an unnamed forum as fact?

Opps. Yah I messed up the naming, I meant exes, but just started typing 64 vs 32 which really is only a memory thing, if you simplify it.

Converting a Win32 exe using UWP Desktop Bridge is stupid easy though. Older exe with a lot of legacy dependencies may be more difficult or lack of source code. In which case they need a virtualization to run those legacy app.

So even though all games/apps fall into this category most companies could have a UWP build ready very quickly.

So for the sake of continuing to hold back technology we are held down by enterprises and DOSGaming.

In all seriousness we complain in the developer community that Internet Explorer and Edge holds back using more modern Javascript yet we make these excuses for OSes.

Almost all programs I use now have a 64-bit executable. If I am using something that needs to run legacy software then I probably don't want the latest version of something to run legacy stuff.

Also the article indicates you can still run 32-bit apps. Most older 32 bit games should run perfectly fine under virtualization. Even then it will be a few years before the majority of Steam user are even using Windows 10 as last I check over 50% were on Windows 7. So by the time gamers shift to Windows 10 i'd imagine their hardware will be more than adequate to handle virtualizing the 32-bit app, I can't imagine there will be much overhead to virtualizing 32-bit apps.

uBlock can't block manual tracking...just third-party scripts that do it.

Example: You visit example-site.com

example-site.com is the php server that sends you the html. It also the site that does the tracking. So when you click something it sends that data to example-site.com and then it can forward the data to a third-party tracking service.

If you blocked or used host files on the server-side pages then the site example-site.com would be completely blocked too.

Ultimately if everyone uses ad-blocks to block tracking script they can be added to the back end. If you block the back-end you effectively block the website you are accessing in the first place.

*wasn't one of the major slow downs

Because they already implemented something similar as per the blog post.

React has an implementation of a virtual Dom. They don't have to use react to do that and as discussed in the blog that is the major slow down on their UI.

That doesn't make sense...the browser always does the rendering of the dom. Not react.

React speed when keeping your states and data in sync is that React makes all changes to the virtual dom then it makes it to the browser dom.

It not different then the concept of batching graphic changes in a 2d game. You blit batches of sprites that need to be changed around the same frame instead of making 500 draw calls you make 1.

Instead of the developer worrying about trying to gather all their dom changes dependent on user interaction and data syncing you interact directly with Reacts vDom and then react takes care of making the dom changes.

Virtual dom frameworks are a huge thing now cause UX/UI are more complex and we were fighting those issue before. Angular, Ember now, Vue, react ect cause we get speed back when making many state changes to our UI.

This has nothing to do with Atom.

That already exists, here is a widely recommended version.

https://nest.com/thermostats/nest-learning-thermostat/overvi...

The weird part about people complaining about the Bixby button is the fact they bought it.

Like why buy it? Did you not see the button when you looked at the product? Did you not read any reviews?

So many other phones to select from and users are buying a phone with a button they don't want.

Companies continue to get away with these poor design decisions and forcing this system-wide apps because we continue to buy their products.

Why can't people get rich while making a difference? These same people could be working for other companies who are not fighting for our privacy and an open web.

I agree that what is considered high paying salary is completely insane these days with wealth inequality and the idea that such sum of money if more than an individual will ever have use for. But that is a different topic.

A non-profit status doesn't always mean charity. In Mozilla case they are a Foundation, another entity eligible for non-profit status. They have different goals than a charity.

One of the things they do to earn this status is grants. And they have lots of grants.

Now what is funny is you exclude the $0 the five Directors made. Also Mitchell Baker doesn't get their entire pay from salary. That why it is in the second column. Last salary report on her was $400k. Which is weird cause that was in 2014 the same as this public disclosure form. Not sure why you purposely left out the fact their salary isn't actually 1 millions. But total compensation.

So their 'disingenuous' nature isn't so black and white as a headline 'non-profit chair has a 1 million dollar salary'.

That's the complete opposite of the way Chrome was designed. I've rarely seen Chrome do a complete lock-up and close everything. The point of Chrome spinning up a new process per tab is that when one Tab crashed it doesn't take out the whole browser.

Firefox on the other hand did this constantly. In fact the only thing that has prevented me going back, and I have regularly given it a try as I support their overall approach and support of web. So I am excited to see how Quantum feels.

But if Chrome was constantly locking up and crashing completely I have to imagine its something wrong with your computer/OS.

So Netflix homepage, not signed in, has no React. It is the page that doesn't even need React.

If you are signed in, then you will not see Netflix landing page and go straight to their app which has React.

I feel people are misunderstanding what Netflix meant in their tweet.

I think you are really misunderstanding what vanilla javascript and HTML really is.

No UI in plain HTMl is scalable. If you have a UI each piece of code needs to be repeated on each page. Have a ten page website?

You need your footer, nav and whatever side bar on each page. Copy and pasted. What it changed? You need to change each and every page.

How did we get around this? WAY back we used server-rendered HTML. The server would serve different pieces, partials, to a piece of content.

This was done largely to PREVENT ugly and repeated code. Because making a simple UI in HTML/Javascript stack is overly repetitive and complicated.

No one needed to make server-side rendered pages to solve that issue but it did make maintaining that website easier. Eventually you could use server-side rendered pages to send data that was tailored to a user too.

This same problem happened on the front-end. Both the back-end and front-end started to use templating languages to help with these kind of repeated code.

The reality is a server creating the UI of a program and sending it to a user was OVER utilizing a server. All applications on a machine render and put together their UI. They utilize their power/cpu to construct those. So Web has started to move those templating languages to the front-end.

Some use build chains to create their pages other use SPA to contain it into one page. But the responsibility to construct the repeated components of the UI have become the clients-side for many sites. A server-rendered site is overkill for most these apps.

Things like middleman, jekyll, gatsby exist to do these for you. Create static pages that have repeatable components.

Pretending that none of these tools were created to actually solve a problem seems like you are ignoring what it's like to actually write a plain html/javascript website with any type of functioning UI.

Any form of website where you repeat components or interaction requires copying and pasting every time you edit 1 piece for every page or we use tools or server-side technology or frameworks to eliminate this.

If you wish to code in that style, in that world, or pick and choose what technology framework solves these problems (Rails, PHP) but complain out other frameworks that are front-end(React, Vue) then you seem to be closing your eyes to the full-stack development. Cause back-end programmers ran into these issues and solved them with templating engines themselves and now we are just doing that for front-end to solve the same issue.

Any type of UX interaction was always messy and not very scalable using older javascript.

Sure it was do-able and libraries like jquery, which have been shown to be slow, made it convient and easy to write it. But ultimately it was messy looking code.

Sure using the basic built-in UX like a button that post a form or a site that just had images on it was simple. Once you added interactivity and the web became a lot more than just dry course dumped information people wanted a way to navigate that.

Even the most simple website can be improved with a hamburger menu to have an always available nav menu instead of the classic scroll to the top or have a fat footer at the bottom.

So a convoluted CSS solution is available by using a <input> type 'checkbox' and seeing if its check in the place of the hamburger.

But really that's shoving your view logic and your ui logic together.

That covers the state of javascript before these libraries. What hacks, work arounds, or messy spaghetti code can we create to make it work. Since it worked for us 10 years ago then making maintainable, readable and sensible code should be considered bizarre and strange?

I see this push back a lot. I think it is cause originally learning HTML, CSS and Javascript was easy compared to what it is now. You learned mostly HTML and CSS and you learned the basic idea of functions and making API calls to the browser like document.getElementById or console.log.

But deep down I've met a lot of these 'older' and 'experienced' javascript developers that wonder why we are moving in such a 'necessary' direction. I find most of them don't really understand programming itself. What the javascript language is doing. What the concepts are. The fact that a lot of calls are to the browser api that are exposed via javascript and not natively part of the 'language' itself. Sure Node has some similar those functions because it's built-in to their library to mimic the similar environment.

Point is, if you enter any other language like Java, Python, C++, C#, Ruby ect, these way we use to code in Javascript were essentially anti-patterns and extremely round-about ways to solve problems instead of using proven design patterns that have been established throughout other languages.

So in conclusion I think the push back is that right now Javascript has become more difficult to learn or adapt at first with the notion that 'its easy'. But the truth is that it has caught up to more mature languages but the browsers have still been lagging behind requiring extra work to learn how to adapt tool chains to build these so they are compatible.

I have no issue with people writing a simple website in React, Vue or whatever SPA or UX framework they want. I think it's crazy if they just serve the straight javascript files as creating static files of their site is rather easy and makes the initial load times to paint quicker and javascript-free friendly. Therefore you get both worlds. Nice maintainable and readable code that is very easy to modify months later with the same benefits of your typical static pages.

Long rant but hopefully you can better see why things moved in this direction even for simple websites.

>Misleading title and some people have already taken the bait.

Curious why you say it's misleading? The title is 'Drive File Stream launching to all G Suite customers' which doesn't say anything more than a new feature or app is coming to ALL G Suite customers.

Not misleading or click bait. I don't know why you think that cause knee-jerks reactions like that also don't help.

What about putting the effort to support Vue or Ember? What happens if they fall out too?

They never suggested those frameworks are dead or inferior. They just made a product and launched it.

I mean I imagine adding support for each framework takes a lot of work and if the audience is too small then they might feel the time was better spent making the current three frameworks work well.

This is the idea of mvp right?

They just released it. Should they have waited until they had X framework that Y person feels they are missing? Maybe 50 frameworks added later they can release it and you'd be happy at that point?

Seems like more negative with nothing really added.

I thought HN had more quality comments but i've been seeing these kind of low-effort comments that are mostly negative that seem more about complaining then being constructive. I hope you can understand where I am coming from and I hope if you enjoyed their product they are considering adding support for a framework you enjoy.

I don't know much about this but I swore I read the chrome uses chroot for its sandboxing. Would that not already accomplish what you wanted?

https://chromium.googlesource.com/chromium/src/+/master/docs...