Ask HN: Could you build an entire web app in just one language? | Hacker News Reader

Ask HN: Could you build an entire web app in just one language?

5 pointsbarmstrong10 comments

I was tutoring someone in web app development recently, and the monumental task in front of him really hit me. He was trying to learn and use at least 9 "languages" at the same time.

This was just one possible stack, but in our case it was.

Ruby - Rails - MySQL - Bash (command line usage) - CSS - HTML - Javascript - JQuery - Git - (Capistrano, Yaml, nginx, ??)

Even though these aren't all true languages, they appear this way to newcomers since they are each a new syntax to learn.

If you slowly built up these skills over 15 years, they are clearly separate concepts in your mind. But for a newcomer trying to use them, it's not even clear which are which.

Is that a Ruby method or a Rails method?

Is "script/server" a shell command or is "ls" part of rails?

Is <a href="..." onclick="..." style="..."></a> html, js, or css?

He made a comment along the lines of "wouldn't it be great if you could build all the pieces of a web app in one language", and I started thinking about it.

GWT (Google Website Toolkit), ActiveRecord, CoffeeScript, and Heroku are all steps in this direction. You could classify them generally as trying to "eliminate a language in the stack" or allowing you to do a piece of the stack in a language you already know.

Obviously there is a trade off here between power and simplicity, but I'm wondering - would it be possible or desirable to get an entire web app down to just one language? If not that how few could you use?

Btw, I think there are benefits to seasoned developers here as well. I remember Lars Rasmussen (creator of Google Maps and Wave) mentioned something to this effect at Google IO in 2009, that GWT allowed him to spend his mental CPU cycles at a higher level and be more creative (not having to worry about cross browser css or js). So the benefits may not only be for newcomers.

This is exactly why JavaScript is going to win. I'm using JavaScript back to front using CouchDB -> NodeJS -> client-side JavaScript. The cognitive overhead of switching from language to language is pretty much gone. Being able to serialize and deserialize objects in the same language is pretty cool. Doing REST calls to Couch spits out JSON stringified data, then a JSON.parse()->JSON.stringify in the middle, and then another JSON.parse() on the client.

This is pretty awesome and I think you're right. If we had to pick one I really wish it wasn't javascript :) But having just one would be very powerful.

There's also a language/tool called Monkey Coder which attempts something along these lines; though it's more aimed at creating apps for the different kind of platforms (iphone, android, html5, mac/pc/linux app, etc). I haven't played with it yet, so can't comment, but if you're interested, check it out here: http://www.monkeycoder.co.nz/

Some of the lisp style stacks get very close as do some smalltalk environments (squeak). Of course this means generating the markup from code but seems to work well enough.

HN is an example (see hn challenge) as is teepeedee2 (http://john.freml.in). Maby clojure is worth a look.

There's XAML, which brings it down to just three languages (Batch, XAML, and C#), but I would not recommend Silverlight for web applications at the moment.

Pretty much anything significant will need SQL, even if Node.JS includes databases, so you write it in JS I'd rather do the sql myself.

Well nodeJS is doing a decent job by having the same language on the server side as on the clientside.

css and html are both markup-lanugages and I find it very strange to add turing-completeness to a markup language.

well there are examples where this IS the case, look at LaTeX for example.

But having html as the frontend, and both clientside and serverside javascript as the backend is the closest that we can get at this moment.

There are JavaScript UI libs that handle the HTML/CSS for you like ExtJS. You'd still need to at least supply a single HTML file that just loads the js files though, but that hardly requires knowing HTML/CSS. After that the whole presentation layer is pretty much defined with JS and JSON.

That's in theory though -- in practice I wouldn't expect to get very far before not knowing html and css became a significant hurdle while developing a web app.

Anyway, these days I wouldn't even suggest building web apps as a starting point for someone's programming related career; it's just too big of a mess of languages, frameworks, and libraries. I think just about any academic curriculum aimed at application development starts off with basic console applications, works up to GUI apps, and then goes to the web. By then hopefully you see some patterns emerge that make learning new tech easier on you.

Then again, ironically, I did start to learn programming via the web through PHP, so I guess it can be done. The thing that helped me was that I already had a few years of experience working with static HTML, and I understood the problems PHP was trying to solve and felt the need for a solution myself. This was in the late 90s or early 2000s though, things were still a lot simpler back then than they are now. Websites didn't absolutely depend on JavaScript, you didn't have to know anything about AJAX, seeing CSS was fancy since having style information in your html was still common.

I don't know, if I think about learning all of it at once from scratch these days I want to vomit and have a seizure. So yeah, to answer the OPs question, I guess I do see how the benefits of unifying and abstracting a lot of the pieces out might be useful.

This whole site is written in arc. period.

...with html, css, sql, a deployment solution, and some handfuls of js.

Reply on news.ycombinator.com