For myself, there are two things that are really pissing me off: 1) Lack of security by default, 2) Lack of choice in client-side scripting. I am at the whim of JavaScript which is pretty terrible. Of course, there is no hope of anyone producing a browser that offers an API, and a set of languages that can access that API. So it's just JS. That's fucked to me. I have more gripes but I'd like to keep this post short.
On the server side, it's easier. We have more choices, because our clients are not tied into a specific server technology; I used to write PHP, but since then I moved on to something that's a lot more thought out for serving webpages. MVC is the ideal for this kind of thing. The server will give the browser what it wants, and this does not concern the customer. On the browser end? We are screwed. There is quite likely nowhere to go.
Unfortunately, we have four big companies (Google, Microsoft, Mozilla and Opera) pouring in a lot of money to keep this technology afloat. And it's very sad. These companies should be leading the way, not holding back technology.
Glad to see things are moving forward. I hope this leads to a more general API later on down the road.
I use coffeescript for all of my javascript development now and life has never been better. I've never used Emscripten in a serious capacity, but both of these projects are under very active development and show that javascript really is becoming the x86 of the web (as stated by Brendan Eich).
No need for us to wait on the four big companies. Things are moving forward without them.
sgk284 is on the mark with emscripten and to a slightly lesser extent coffeescript. But another project to keep an eye on is Google's Native Client, particularly the paradoxically-named Portable Native Client (PNaCl). If anything becomes the next standard scripting extension to the browser, PNaCl stands a good chance of being it, IMO. Once we have that, the browser really isn't much inferior to any other applications platform.
I'm guessing it will become more of a focus for Google as their Chrome OS matures. If it's a big success for Chrome, perhaps it'll spread elsewhere.
I have a silly, fictional view of the future: That every website will be HTTPS by default, and instead of Firefox/Chrome/etc using a "green" bar to tell a secure website, it will not say anything, but will display big red warnings when a website is not secure.
In Chrome and IE its one or two clicks. I don't know why people tolerate Firefox's silly "ZOMG THIS SSL CERT MIGHT BE WRONG" 90-click UI. Joe Averge is still going to run through the clicks. Badgering the user with more prompts has been shown to not increase security and only frustrate power users.
The problem is that there aren't enough IPv4 IP address for this. Each SSL cert requires an IP address. So if you have 200 sites on one virtual setup with one IP, only one of them can have the SSL. The connection needs to be established before Apache or IIS can be told what site to serve.
Maybe v6 will solve this, but right now you simply cannot do this. Or maybe the spec can be changed somehow (ask for host first then start SSL handshake?).
I am probably in the minority on HN thinking this, and it's a pity that there is no chance of this ever changing, but lets go with it anyway:
HTML, CSS and JS are a very bad way to create websites today. It could be worse, but it's bad enough. They were decent once, when we didn't need them to the extent that people are using them today.
As others have mentioned, the signs of this problem is when people are writing language X to language Y converters to accomplish the same job, because language Y is detestable. This would be your HTML, CSS and JS. Tools like HAML, SASS and CoffeeScript are a very good sign of this.
For myself, there are two things that are really pissing me off: 1) Lack of security by default, 2) Lack of choice in client-side scripting. I am at the whim of JavaScript which is pretty terrible. Of course, there is no hope of anyone producing a browser that offers an API, and a set of languages that can access that API. So it's just JS. That's fucked to me. I have more gripes but I'd like to keep this post short.
On the server side, it's easier. We have more choices, because our clients are not tied into a specific server technology; I used to write PHP, but since then I moved on to something that's a lot more thought out for serving webpages. MVC is the ideal for this kind of thing. The server will give the browser what it wants, and this does not concern the customer. On the browser end? We are screwed. There is quite likely nowhere to go.
Unfortunately, we have four big companies (Google, Microsoft, Mozilla and Opera) pouring in a lot of money to keep this technology afloat. And it's very sad. These companies should be leading the way, not holding back technology.
HTML, CSS, and JS are actually pretty good at doing what they were made to do. Unfortunately, that vision bore little or no likeness to modern web applications.
The time is ripe for changing the way people use the internet, and I think that is part of what the whole "native app markets" thing is about. The problem with that is multiple platforms - multiple browsers together with their cesspool of languages pale in comparison to the pain of developing for multiple platforms. There have obviously been a lot of attempts to make it easier, but they all sucked in their own way.
It will get better, and we'll have new things to complain about at some point. Until then, developing for the web means cobbling together antiquated standards and forcing them to do things previously unheard of. Which, ultimately, is kind of fun.
EDIT: If anyone else is interested in discussing what a solution could look like, I'd love to chat about it. Would certainly be a very fun (if not extremely ambitious) open source project. (Contact through my profile.)
I agree completely. Javascript is just a bad language(1), and HTML and CSS are fundamentally unsuited for the kinds of apps that we're using them for. After years of effort we've managed to get to the point where they sort of work, but it could have been much better.
(1) Yes, I know the cool things you can do with closures. Python and Ruby do them too, without the insane misfeatures like default global scope and bizarre implicit type conversions.
Ruby has decent lambdas/closures, but Python absolutely does not. Its lambas are horrifically limited. Because of that alone, Javascript is a much better at functional programming than Python.
I agree that default global scope is a misfeature, but the solution is trivial--declaring variables--which I think makes the language much more readable anyway. I quite dislike the Python style of coding in which the local variables are just causally used without listing them somewhere--it's too easy for things to get lost. On the other hand, maybe I just need better syntax highlighting? The new "use strict" should completely fix accidental globals, as I understand it.
People complain about the implicit type conversions but I'm not sure I've had that pose a problem in real life and I've written my share of Javascript. I'm not even sure what that kind of bug would look like. I'd love an example.
Another fan of your writings. I like the occasional quote you throw in there. However:
I don't agree with the way you phrased your headings. Verging on linkbait, even.
RCE is a hobby of mine and I crack all sorts of shit; it's fun and challenging. I know quite a few people who do.
This is the first time I have read such a blunt "I can crack your..."/"How to stop me" approach. It sounded very arrogant at first. No one else that I know bothers with this direct attitude. I am sure Mac devs are more than aware (Anticipating an article on this as a followup to your post).
"[...] but implementing a bare minimum of security will weed out 99% of amateurs. [...]"
I am not sure where you pulled that number from but it's false. RCE is not as difficult as you make it out to be, and amateurs can overcome the usual barriers quickly. Communities thrive on teaching amateurs the art, and they pick up these skills very quickly. I taught a few.
Been holding this one back for awhile, but: Are there any talks, plans or otherwise on incorporating other languages for client-side scripting? I'd really just like to get away from JS in general :(
IMHO it will never happen in the sense you imagine it but we'll see.
In the meantime you may want to check out emscripten (http://code.google.com/p/emscripten/). It is a JavaScript backend for LLVM which ultimately leads to the same functionality as having other languages on the client.
Night owl coder here. It comes with the job I think, our job is creative and our minds toy with us to no end.
I have found I can "cut off" the deep thoughts by writing them down. I keep a notebook next to my bed and if I can't fall asleep because of something I want to program, I will write out everything about it in the notebook. After that, I'm far more relaxed because I am not worried about losing the knowledge once I fall asleep.
I'm trying to prevent myself from being baited into making a website out of all this--i'm booked, but it is definitely something that the HN community should band together and provide. It sounds _very useful_.
Stepping on * a lot * of toes with these kind of posts. They are the cold truth and people aren't used to it.
Internet and social addictions are real. There are many IRC chatrooms that are filled with people who haven't done anything, not a single finished project or any sort of plan with their lives, because they are too busy filling the craving of talking about whatever, or "planning" to do something/"hoping" to finish a project, and so on.
I'm also someone who has recently shook off gaming. A friend of mine tells me I am doing it wrong because I should be enjoying life, however looking back I sank way too much into SC1, Day of Defeat, Counterstrike, and was almost baited by SC2--the same games that Matt Rix mentions.
I prefer to play Single Player nowadays because there is a definitive start and finish. This acts as a cue for me to get back to work if I have been slacking off too much.
For me, once I get over the initial plateau of starting up again from where I last left off on a project, the feeling of laziness and procrastination goes away. Again, Matt mentions knowing the concrete things you wish to do and then executing them. It works for me(tm).
Very nice presentation. I'll be passing this along to colleagues.
However--isn't this how most web apps are made? The domain-driven design of model->model interactions->front-end design has been around for a long time now hasn't it? I was hoping for something more to come up as I was watching the presentation.
The apps I do by myself pretty much follow what Ryan Singer outlined. It works very well, and once the code has been sanity checked to work I get started on a "high fidelity" version of the front-end and just play with Photoshop until the look is there. 20-25% of time spent is in a notebook full of class diagrams, database tables and lo-fi wireframes, rationalizing what models make sense for the app, how they will interact, what the user/admin will see, etc.
For myself, there are two things that are really pissing me off: 1) Lack of security by default, 2) Lack of choice in client-side scripting. I am at the whim of JavaScript which is pretty terrible. Of course, there is no hope of anyone producing a browser that offers an API, and a set of languages that can access that API. So it's just JS. That's fucked to me. I have more gripes but I'd like to keep this post short. On the server side, it's easier. We have more choices, because our clients are not tied into a specific server technology; I used to write PHP, but since then I moved on to something that's a lot more thought out for serving webpages. MVC is the ideal for this kind of thing. The server will give the browser what it wants, and this does not concern the customer. On the browser end? We are screwed. There is quite likely nowhere to go. Unfortunately, we have four big companies (Google, Microsoft, Mozilla and Opera) pouring in a lot of money to keep this technology afloat. And it's very sad. These companies should be leading the way, not holding back technology.
Glad to see things are moving forward. I hope this leads to a more general API later on down the road.