This is such an odd statement as it's already been proven false. The Echo is already quite popular. I gave one to my 70 year old technophobe mom and she uses it in the kitchen all the time. I use mine everyday.
My guess is in general the Real Estate market doesn't want this. What happens if it tests positive for something? Do you start tearing down all the walls until you find the issue? Suddenly the house is unsellable and a huge money pit for the seller or new buyer.
I get that it's trying to be funny, but is it really no longer possible to create a website with a single arrow that doesn't have to pull down all this cruft ?
Agreed. I was curious as to how the random numbers were being generated (math.random()? Something else?), so I went to look at the source code. I expected `assets/js/src/application.js` to be the main file (I mean, look at that name. What else would it be?)
I start reading the code, and pretty soon it starts messing with the clipboard, and it even pulls in Flash [1]:
> // Config ZeroClipboard
> ZeroClipboard.config({
> moviePath: '/assets/flash/ZeroClipboard.swf',
> hoverClass: 'btn-clipboard-hover'
> })
In all honesty, this website serves more as an indication of why the TSA spending this much money on such code may actually be justified, rather than effectively mocking the cost, which I think was its intent. How many security holes do you think this website is subject to? Can we know for certain that none of these dependencies are malicious or contain backdoors?
Security can't be taken lightly. And yes - for an app like this, it's much more important that it be secure than that it look good. I doubt a browser application is really the right approach anyway, given those concerns.
Javascript is getting freakishly absurd. What is wrong with the JS ecosystem? This feels like XML all over again.
I know not all engineers do this, but this crap is what caused me to buy a new laptop. I was fine with my existing tools and workflow, but websites have gotten so slow and ridiculous. It's largely Javascript's fault.
I used to get angry about walled garden app stores, but lately I find myself hating the web. I don't dislike it, but I think we went on a really lame detour.
As an aside, Javascript ads are worse than Flash ads ever were.
In this case a few lines of CSS and a few lines of JavaScript would have delivered the exact same result, including all necessary responsiveness. We have gotten so far away from bare bones, non-jquery based development that this kind of heft has become the standard starting point for all projects. It certainly isn't my style, but then I didn't go to Stanford and don't work for a unicorn, so perhaps I am the unenlightened one.
That said, I don't think it's necessary to criticize a satirical project like this on technical grounds. The idea is great; the developer probably just used his boilerplate frameworks that are usually used for much more complex projects in order to save time.
Make 300k off a website and people make a competitor to mock the value you delivered. People are stupid and you can't win. They will always try to force everyone to race to the bottom, because if they can't have it why should you?
No it needs to work in any hn readers browser. Different business requirements entirely! The business case here is to get hn traffic to that site and start a discussion.
I'd love to see a ridiculously over-engineered version. Something like a website running in a browser in Windows 95 running in a javascript DOSBOX emulator.
They are probably just using a quickstart file that has all of those things included as defaults.
I have a repo I clone for my one-off projects with all the boilerplate I could possibly need for a weekend project. None of the projects actually end up using all of that stuff, but I'm not bothered by the lack of professional optimization in my "for fun only" projects.
Not that it makes the problem of being a developer who may need to convince other developers they're a good developer go away. Just that it puts the problem in context and shows a way one might be able to make it go away.
Yeah, I hear you I get funny looks every time I make fun of 'whatever driven development', 'microservices', etc. It works well as I generally dislike working on teams that are just following fads.
Let's say you have a mobile app used by 1 billion people every day. It sounds crazy, but I bet a fair number of people in this forum contribute to such an application.
Imagine you want to make an optimization that increases battery life by 1%. Assume a 30Wh battery and that it's charged once per day. Over the two year lifetime of the phone, at $0.10 per KWh, that change would save your users 21.9 million dollars in aggregate. Even with a team of 40 people making $500,000 per year working for a year, you still increase the efficiency of society with that change!
(I know, this ignores the opportunity cost of adding a new feature before your competitor, or focusing on something that will bring more user happiness, or the externality that users don't notice the $0.00003 they're paying to supply your app with electricity. But the point is, we have a lot of power, and our time is much cheaper when multiplied proportionally to that impact.)
Similarly, my general rule for optimization is: Add up all the time that will ever be spent waiting on this code by all users ever. If that's less than the time required to implement the optimization, don't bother.
That eliminates a surprising number of tempting gold-plating situations that occur in rarely-executed code.
On the other hand, cutting 1 second of wait from a million daily active users adds up to whole human lifetimes saved rather quickly.
The usual (and frankly convincing) argument is that you won't get to a billion users without using the cruft as a means of scaffolding to help change and iterate and try new features, whatever the behind the scenes architecture looks like
Then, when you have 100 million users, you can afford a team of optimisation specialists to strip out that 1% battery life
But yes, it seems on average npm pulls in 1,000 upstream packages when you just try making a vanilla project of any complexity
I think what your actual objection is that it's so easy to make a simple website with all that cruft. Much or all of that stuff comes in one of the easiest to find and download "starter packs" from Bootstrap. You can take the time to figure out what everything does and slim it down or just ship it.
Exactly! My first attempt was just 10 lines of HTML code, but it was a real pain to do the vertical centering on iOS. So I tried a Bootstrap template, saw that even they didn't do the centering on iOS, but was too lazy to change it back.
Part of that is right out of the Microsoft playbook. Promote you right before the review cycle. Give you a bad review by comparing you to all your peers in your new level. They had a limited number of promotions and good scores to give out. This way they didn't have to give a promotion and high score to the same person.
When I worked at Microsoft many years ago they had an large QA team with equal footing to Development and Product in determining what shipped and when. This was the same for every development team I was a part of there for over 9 years. It wasn't perfect, and the ship cycles were slow, but the quality bar was set higher than what I've seen outside of Microsoft.
That's not correct. Apple doesn't allowing purchasing digital goods through a non-apple payment method. The margins are so low for Amazon it doesn't make sense to give apple 30% for every kindle book purchased.
Why would they have keywords added? Adding `mutating` to a func in a class is invalid, because the very concept makes no sense. The `mutating` keyword can only apply to value types, because it means "this func mutates the value in-place, so it needs mutable storage to invoke it."
The "bug," if there can be said to be one at all (I don't see it), is that Swift collection types are value types, while Objective-C collection types are reference types. But given this difference, the lack of `mutating` on the mutating methods makes complete sense, and adding it would be bizarre, since it would be an error if you did it in your own code.
It's not like anything you build in React is going to transfer over to another framework either. In fact, I've been to a lot of React talks and people mostly ask "how do I do X" in react. The last talk I went to they spent 10 mins talking about how you might make a spinner when data is loading.
React is a rendering engine, it's covers the final piece of your web app (rendering a data structure into DOM). But whatever you do to create the data structure that gets passed to React is up to you. This keeps most of your domain logic outside the context of React, you just use React to render data->DOM. So basically the API you have to learn is just Javascript, which most people know already and is easy to lookup answers to your questions.
With Angular your domain logic exists in the context of the framework. i.e. if you ng-repeat something you can't just filter that collection with Javascript you have to use an ng-filter to do it which is a special Angular construct. So the API you have to learn to manipulate data isn't just Javascript it's Angular. And how does ng-filter work? Well, you're tied to the Angular docs to figure it out. The Angular docs are of particualary poor quality so this coupling turns into a really serious problem if you're trying to be productive.
To me React vs. Angular isn't a matter of preference like Ruby vs. Python -- it's more like git vs. FTP where there is a clear right answer if you're trying to be productive in a team envrionment.
Sigh... this is such an annoying comparison. If you want to compare, compare React to Angular Directives since that's a valid argument.
Your entire complaint is that full-stack front-end frameworks are bad and modular systems are good. It's great that you prefer modularity and the ability to mix and match tools.
But stop pretending React vs Angular is a thing. It isn't. git vs FTP... just stop.
