

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

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.<p>This was just one possible stack, but in our case it was.<p>Ruby
- Rails
- MySQL
- Bash (command line usage)
- CSS
- HTML
- Javascript
- JQuery
- Git
- (Capistrano, Yaml, nginx, ??)<p>Even though these aren't all true languages, they appear this way to newcomers since they are each a new syntax to learn.<p>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.<p>Is that a Ruby method or a Rails method?<p>Is "script/server" a shell command or is "ls" part of rails?<p>Is &#60;a href="..." onclick="..." style="..."&#62;&#60;/a&#62; html, js, or css?<p>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.<p>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.<p>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?<p>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.
======
dstein
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.

~~~
barmstrong
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.

------
JohnLBevan
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/>

------
catch404
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.

------
Jarred
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.

------
tobylane
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.

------
arianvp
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.

~~~
nxn
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.

------
naughtysriram
This whole site is written in arc. period.

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

