react redux reselect aphrodite material-ui stylz redux-form react-helmet webpack faker lodash moment
react redux reselect aphrodite material-ui stylz redux-form react-helmet webpack faker lodash moment
I mean the site comes in at around 500kb transferred. That's not small, but it's also not obscenely large. A single large-ish image can easily blow that out of the water.
Yeah, it could afford to lose some weight in the javascript (although looking at it now, i'm not sure they can. much of the size of the javascript is string literals for all of the options for each phrase), but for a one-off website that doesn't have any ads or source of income, i think it's great. The author clearly wanted to make something cool, and doesn't want to spend a significant amount of time or effort optimizing it perfectly since he probably won't make a dime from it.
> Do you actually have a problem that any of those are causing?
Inability to select the text.Why? I'm not sure, but that has nothing to do with any of the libraries listed, or even javascript at all.
With JavaScript turned off (an essential security precaution), no text is visible at all, which is a bit of a problem.
> I mean the site comes in at around 500kb transferred. That's not small, but it's also not obscenely large.
The actual content on the page really isn't that large. I got too bored to actually complete this, but you can see an example of what it could have looked like at http://pastebin.com/DBgK4Tv9
It could have progressively enhanced itself, taking the plain-text HTML page, parsing out the choices in the em tags (which could of course have had classes attached to mark them as choices, or even to indicate classes of choices, e.g. 'day-name'). It would have been a perfectly useful tool for people without JavaScript; it would have been perfectly useful printed on a page.
And, frankly, it would almost certainly have been a lot smaller than 500K.
That doesn't take away from how cool it is: the author did a nice, exhaustive job (so exhausted I got exhausted trying to recreate it). He should be commended for it. But we should all reflect on how we got into a situation in which the easiest thing for him to do was the wrong thing, and how we can instead get into a situation where the easy thing is the right thing.
As for the rest, there's also the point that the author probably wouldn't have done this that way. That seems like a dumb sentence, but hopefully i can explain it.
This kind of thing isn't going to make any money, even with ads this is an niche thing and would probably end up making him tens of dollars at most (unless he got really lucky). That means that most likely his motivation was to "show off" a bit. Show potential employers that he can use those technologies, show off his professional skill, and at the same time solve a problem that he saw himself. So most likely it wouldn't have been made without those technologies.
But either way, I don't think that this is the wrong way of doing things. I know that many disagree with me, but for most "web apps" progressive enhancement is dead. Yeah, for a simple company website, or something which should be accessed by as many people as possible like government websites, PE is still very alive, but for everything else, it's done. Javascript is part of the platform, and disabling javascript but still expecting a fully useful web is like disabling python and still expecting all of your linux tools to work the same (after all, those same devs could have written their code in C, then progressively enhanced it with python).
It's part of the platform, and it's here to stay. Disabling javascript is not the solution to security issues.
It shouldn't be, it really shouldn't be. The web should be about GETing, PUTting, POSTting & DELET(E)ing resources (i.e., documents); it shouldn't about GETting executables.
There's definitely a place in the world for a well-thought out universal executable platform, but HTTP + HTML + CSS + JavaScript ain't it.
Progressive enhancement is a good thing: a document which used JavaScript to become a better, live version of itself would be better than an ASCII list of neat things doable with the Google interface; it'd be better than a static HTML document. And it'd be better than a single-page app.
> It's part of the platform, and it's here to stay.
JavaScript delenda est.
See, but why shouldn't it be?
Would it be valid for me to say that python shouldn't be a part of linux? That people should stop using python on their linux command line tools because linux is really about C.
The web is an application platform, and I still haven't heard any convincing arguments as why we shouldn't use it as one besides "Because it wasn't one in the past".
I agree that progressive enhancement is a good thing, and in a perfect world every application would start with the bare minimum and work up the "technology tree" to get to the latest and greatest, but in the real world of limited time and money that's almost never possible. Having something that's not perfect is better than not having anything at all.
Somewhat fair point, but at least it would cut out the number of language runtimes one has to have on a Linux computer. For simple command-line tools, besides C/C++, you end up needing Perl, Python, Ruby, and now probably also Go and Rust.
> Having something that's not perfect is better than not having anything at all.
Arguable. The Internet is a perfect example of having a lot of things that would be better off not existing in the first place. Like, e.g., most of the sites for which ads are the only viable business model. But that's a longer discussion.
I think the important point is that, while the individual choices of a software engineer in a particular time and moment can be excused, the trend as a whole is pushing us towards increasingly batshit insane pseudo-engineering.
A static list like that should not need anything more than plain HTML/CSS and a little bit of JavaScript sprinkled on top to do the click effects. That people end up using shit ton of frameworks and external services for simple sites (this one is far from the only case) suggests that there's something very wrong with the industry as a whole. It's worth identifying it and figuring out how to fix it.
I just can't agree with that. Sure, there are things like malware which shouldn't exist, but outside of that I just can't agree that something shouldn't exist because some don't like the business model (or the technology used).
>A static list like that should not need anything more than plain HTML/CSS and a little bit of JavaScript sprinkled on top to do the click effects.
It doesn't need more than that, but having more than that provides a lot of benefits. A nicer look and feel, a more "responsive" view in terms of massively changing UI depending on the screen size, inline search, a unique and pretty useful way of showing different possibilities of each phrase, etc... All while being very simple to make (which is an extremely important point for something like this).
I know many people don't like those things, but to dismiss them as "something very wrong with the industry" is incorrect in my view. People want eye-candy, and they want it instantly. If they can't get it through the web, they will get it through downloaded applications, or apps in closed app stores, or some other methods that we haven't even thought up yet. And blaming people for wanting it isn't the answer, nor is "fixing" it against their will.
Just like how you could make this website with plain html, then layer css and javascript on top to make it look nicer, you could make a package manager on linux that has 0 dependencies, then add python and perl to enhance it. But nobody has the time or money for that, and in the grand scheme of things it's not going to hurt anyone.
This is a website about voice commands that you can say to your phone, have them sent to google, analyzed, and a result sent back (which might go to a search page which uses more data than this whole site does). Building the website in the way you feel it should would not have improved live for many people at all, and it would have possibly made the author never want to make it in the first place.
User experience.
- long, unskippable animation on site load
- navigation keys (arrows, page up/down) do not work at all without changing focus first (which takes 4 tabs)
- navigation keys do not work at all in category list (items can't be selected or scrolled)
- mousing over items produces unexpected results (text changing, distracting animation)
These may not be caused by the technologies per say, but more generally by the 'form over function' attitude.
Why does everything on the web have to be so fancy these days?
It needs some work with focusable things, I needed to use the special navigation keys (I tested with ChromeVox on the desktop) to get to the lists on the left and right, and to click on anything i had to use the special "click" keybinding instead of pressing enter, but it's 100% usable.
On android it works great, about the same as any other website or app (i used the android accessibility screen reader to test)
Modern screen readers are just as capable as the rest of the browser, the only place they fall short is in image-heavy sites that don't have alt tags. Obviously you can greatly help by adding things like aria tags, and using markup as much as possible, but it's not like they just don't run javascript.
I don't have a mac on hand right now, but VoiceOver relies heavily on tags, so i'd bet the problem is that he is using divs for everything.
Make each thing on the left render in an <li> and use header elements at the top of each block of commands and it should work fine.
So without knowing what's on it, maybe a smaller size could have kept it from falling over.
Looking at the source, I guess, for example, that the questions "How old is X" are all where X is
"Adam Sandler", "Adele", "Akon", "Alec Baldwin" "Alicia Keys", "Alyssa Milano", "Angelina Jolie", "Ashton Kutcher", "Avril Lavigne", "Barack Obama", "Barbra Streisand", "Ben Stiller", "Beyonce", "Bill Gates", "Bob Marley", "Brad Pitt", "Britney Spears", "Cameron Diaz", "Carmen Electra", "Catherine Zeta Jones", "Charlie Sheen", "Chris Brown", "Christina Aguilera", "Cindy Crawford", "Daniel Radcliffe", "David Beckham", "David Duchovny", "Demi Moore", "Dr House", "Drake", "Drew Barrymore", "Eddie Murphy", "Eminem", "George Clooney", "Gwen Stefani", "Halle Berry", "Hugh Grant", "Jack Nicholson", "James Cameron", "Jason Statham", "Jay Z", "Jennifer Aniston", "Jennifer Lopez", "Jennifer Love Hewitt", "Jessica Alba", "Johnny Depp", "Julia Roberts", "Justin Bieber", "Justin Timberlake", "Katherine Heigl", "Katy Perry", "Kelli Williams", "Kesha", "Kevin Costner", "Kim Kardashian", "Kristen Stewart", "Lady Gaga", "Leonardo DiCaprio", "Lil Wayne", "Lionel Messi", "Madonna", "Marilyn Manson", "Marilyn Monroe", "Megan Fox", "Michael Douglas", "Michael Jackson", "Michael Jordan", "Michelle Obama", "Mike Tyson", "Miley Cyrus", "Muhammad Ali", "Nicki Minaj", "Nicolas Cage", "Nicole Kidman", "Oprah Winfrey", "Paris Hilton", "Pink", "Reese Witherspoon", "Rihanna", "Robert De Niro", "Robert Pattinson", "Roger Federer", "Ronaldo", "Sandra Bullock", "Sarah Jessica Parker", "Scarlett Johansson", "Selena Gomez", "Shakira", "Stephenie Meyer", "Steve Jobs", "Steven Spielberg", "Taylor Swift", "Tiger Woods", "Tom Cruise", "Tom Hanks", "Tyler Perry", "Uma Thurman", "Whoopi Goldberg", "Will Smith", "Woody Allen",
It's easier to look at the list than to click every time for one random item from it.
Interestingly, the first person Google recommends to me when I type "how old is" is not on the list.
All this for a static list, he could have just faxed us all this list instead like in the good old times.
Since we're going there - bloating your website for no reason whatsoever wastes electricity. Not just for the mobile users who may be annoyed by fast-draining battery; also in general, you're literally wasting coal.
It's worth at least keeping in mind when deciding to include that another JS framework to save yourself 10 minutes of typing.
I tend to think of CPU time as an almost inexhaustible resource for a website. It needs to be responsive, but the difference between the user's machine being at 5% or 10% CPU doesn't matter.
Moreover, your website isn't the center of the world and the most important thing for user. If every developer follows this line of thinking, then the difference between 5% and 10% of user's CPU time is the difference between them having 20 or 10 browser tabs open before the whole computer slows down to a crawl. Bloating your site means making your users' computers less useful.
And, it only happens once, instead of wasting a tiny bit of electricity for computing the exact same thing for every visitor.