Ask HN: Any web startups using Java?
Based on my observation, most of the web startups are using either PHP or RoR or some other platform, but not Java. I haven't come across a single startup which is using Java for web app development.
1) Is it because of the lack of hosting support for Java based web applications?
2) Or, are there any serious performance issues when Java is used to develop web2.0 apps?
3) Any startups that already successfully using Java?
163 comments
[ 4.1 ms ] story [ 198 ms ] threadThere's an impression that RoR is the language of choice for hackers because so many web-apps are built by it.
Web consulting firms use Java all the time because it's a proven technology with tons of flexibility. In RoR, the moment you step outside of the conventional MVC model; you are pretty much hosed, you have to write from scratch a lot of stuff that folks in Java have already enterprise platforms for. Specifically, if you want to do crazy data modeling with custom lazy-loading/cascading; or if you want to integrate some kind of high performance message system client-side; or have some kind of custom encoding/decoding of data objects from server-side to client-side (e.g., Rails to Flex/Silverlight). You pretty much have to rip up the whole rails framework.
RoR/Python is programmer's proverbial hipsterism to show how hip you are. But I would rather use Java when I need to deliver in actuality since you can't get laid anyways by impressing programmers.
It's a baloney-ass straw man to set up Rails as weak when compared to Java. Rails is a limited web framework, and Java is a programming language.
Instead, you should compare Ruby or Python to Java for web development. If it's still your position that there aren't enough good open-source tools in Ruby or Python to do what you need, then I believe you're either looking very hard, or you're looking in the wrong places.
Tweaking a Java library is huge PITA, because Java is soooo code-heavy. I estimate Java leads to ~10x as many lines of code when compared to Ruby or Python for basic libraries like API clients. The IDE-reliance inherent in that culture removes many of the immediate incentives of code minimalism, and as such, you often find insanely convoluted libraries that literally have more classes than pieces of functionality.
Java's great if you're not in a hurry, or if your organization is infected with enough bureaucracy that the added bureaucracy in the code won't even make a dent in your already-dismal efficiency, or if you need to "get fat" (i.e. "hire a bunch of college grads and burn them out") and you don't mind dropping your talent density to near-zero figures.
With all talent being equal, give me a Python or Ruby shop over a Java shop any day, and I'm certain they will be significantly more productive, day in and day out.
We've deployed a reasonable sized startup codebase for our project without paying a dime for tools and libraries.
Plus, we were also able to carry our Java coding skills across into our Android mobile app development.
I think there are pros and cons to most languages.
I'm just working on my web startup using Groovy and Grails and many things I need are provided out of the box or through plugins (security, search) that are easy to install, configure and use.
I think you should consider platforms as a whole and not just the languages.
The downside is that Jython throws more runtime exceptions. OTOH it has incentivized a ramp-up in unit testing (Maven, Selenium).
1 - we self host
2 - the relevant performance issue when using java to develop web apps is it's slower to build. I'd be pretty surprised if there were many cases where java / tomcat is slower to execute than rails or django. Now obviously all three are smoked by cached pages, but since a lot of our data needs to be updated daily, that isn't the easiest design for us.
As (almost) always, performance issues are with the db. And, as always, you should think about the data structure that you're using.
These days there is basically no reason to do webdevelopment in Java - even if you have legacy stuff lying around, JRuby or Scala will serve you much better and neither is that hard to learn and both will get you over Javas sever limitations (really, no anonymous functions? No Closures?)
A web application is often more than the choice web framework. When you choose Java as your fundamental technology you could build your business logic e.g. in Java/Scala and your web tier in Ruby on Rails which you can run on JRuby.
At least, that's probably the choice I'd make... :)
It works very well. You get close to the performance of C code in a 'safe' language, but can write the non-performance-critical code in a less verbose language of your choice.
Java is mostly snubbed in web startup land and associated with boring corporate work.
More discussion here: http://news.ycombinator.com/item?id=1378815
I bet there's a whole other demographic of serious business people who are busy getting things done instead of discussing unrelated matters, or in other words, doing things that aren't work-related.
Despite all the bad news you might hear, as long as you stay clear of the bloated enterprise stuff it's a great platform and environment for a startup.
Hosting used to be an impediment but these days VPS make it dead easy to run Java stuff.
by this you mean the frameworks like Spring, Struts or the buzzwords like JMS, EJBs?
There are two things I really like about Java in the broad sense: the excellent Eclipse environment, and the multitude of quality open source libraries.
http://www.adobocode.com/spring/adding-crud-capability-to-sp...
I'm personally into much simpler stuff like Stripes & Guice.
Take a look for example at the family of spring MVC controllers (http://static.springsource.org/spring/docs/2.5.x/api/org/spr...) : before doing any development, should you have to study such a family to know which controller should fit everyone of your use cases ? That, for me is the very definition of bloat.
Furthermore, the documentation is terrible, IMHO. That said, I have been spoiled by months of Django development, maybe it is not that bad according to Java Standards.
More generally, the main problem with Java is the emphasis on architecture astronautism, not the language itself, which is ok, if not very powerful (no function as first class objects, really ? ).
And it is easy to use Java EE components like these without the need for frameworks like Spring - if anything I think they just obscure what's really going on. Again I'd like to re-iterate I'm not a highly experienced developer but I've learnt how to use most of the Java EE technologies in my applications rather quickly.
avoid IDE's -- or at least, anything that causes your team to need an IDE just to counter-act some other linguistic or procedural vomit you often encounter in the typical Enterprise Java shop
avoid abstraction-for-the-sake-of-abstraction -- the Java ecosystem, not necessarily the language, is notorious for this
We don't use JEE in any form, but the Java language and runtime is used and works extremely well on the cloud infrastructures. We built out a very simple upgrade mechanism to roll out new code, and by keeping components independent of each other we can scale our infrastructure easily.
http://www.playframework.org/
http://www.zeroturnaround.com/jrebel/
CF and it's community is not the same beast it used to be, I would encourage you and others to take a second look.
EDIT (Summary): We knew Java well early on and so used it to prove a market, leveraging open source libraries along the way. Do I think Java the language was a particular competitive advantage to us? No. But do I think any of PHP, Ruby or Python would have been either? No. (Lisp - probably yes! but we don't know it well enough to use professionally). To be honest, our main concern early on is to release early and prove the market, with whatever tools we can use.
Why did you stop using Tapestry? Because Howard Lewis Ship is a liar. Lots of reasons but the main one was breaking compatibility between v3 and v4. Just when we solved all those issues v5 came out and broke backwards compatibility again! Just couldn't go through that again.
Ideally, I would like to have a lean version of maven+jetty+spring to implement a web framework.. which should also be deployable to more heavyweight containers like JBoss. I havent figured this part out. Maybe Stripes is the way.
Since we come from enterprise environment Java is the second mother tongue to us and I have got accustomed to mighty autocomplete and refactoring features of eclipse. The main reason for diverting from Java would be purely of taking intelectual pleasure in learning new things and checking if python/ruby frameworks live to the expectations.
We did some contract work on french social startup using a very lightweight web framework called Stripes (http://www.stripesframework.org). It was much better experience that using component based UI frameworks like JSF.
Needless to say - for quick web hacking I still fall back to PHP.
Java is great for rapid development once the development process is set up correctly. I've actually ported the app to Google App Engine in the middle of development once I learned of its generous hosting plan. Java is one of the two languages supported by GAE. I did use Python for quick scripts in import/export and building up data sets from dev environment to production servers.
I'm a long term Python developer (since the 1.5.2 days). I've used a lot of different languages so far (from C to Haskell), and I've always avoided Java in the past (at the beginning because it was slow, later because everyone was telling me how bloated it is).
But using Java EE (!) instead of Python for a project a few months ago was really an enlightenment. Yes, it is somewhat bloated (although much less in the recent versions where you can use annotations instead of all those XML files). But on the other hand: It just works - exactly as documented.
With all other frameworks (based on Python, Ruby, etc.) that I've used so far I had to hack around in the framework or in the libraries to make it work the way I want. This starts with simple issues such as Unicode support, where the authors of a library obviously just didn't care if it works, and continues with distributed transactions, where you have to hack up the whole logic inside your application because the framework doesn't support them. Compared to this, with Java (EE) this just works rock stable and has most of the features you'll ever need.
From a performance perspective Java isn't that bad as either. For a project I've compared the performance of two simple (comparable) Web apps that I've wrote: One with Python on Django, the other one with Java on Glassfish). Once you increase the concurrency, the requests to the Django app just return error codes or take a long time to complete. In comparison, the Glassfish app just chucks happily along.
This does not mean that Java is appropriate for all use cases. But just don't believe the majority and try out yourself, if it works for you.
I would even say you could go as far as saying it one end of the spectrum. Where you have frontend web apps (html/js/css) on a variety of platforms[1] on the one end and the big corporate backed languages and frameworks on the other end.
[1]: This can be a real pita. Though it's being mitigated more and more by adding compatibility layers on top (jQuery et al).
Usually the solution in the dynamic language is far more elegant and satisfying than the Java version, but there might have been a lot more trial and error involved in arriving at the solution in the dynamic language.
More correct, second reaction: deploying Java apps can be more enterprisey (depending on how much of the J2EE stack you're laboring under) but at least has well-known production-quality deployment options. This is an area where the community could use some serious consolidation.
If your observation is based on reading HN, likely it's a bit skewed. Paul Graham has bashed Java and Java programmers quite a bit in his writings: "The programmers you'll be able to hire to work on a Java project won't be as smart as the ones you could get to work on a project written in Python."
That said, I would have to agree that Java is not the language of choice for small startups. There is a lot of overhead involved in setting up a Java project compared to other languages/platforms, and the problems that Java is best at solving aren't usually the problems you run into in a small web app (unless you're dealing with a lot of data).
Java isn't as fun to use as newer languages, and doesn't have the vibrant community that Ruby and Python do (even if you include JVM based languages like Scala and Groovy). Java doesn't attract creative types. A web designer looking to pick up a first backend programming language is probably not going to choose Java, and thus they aren't going to create beautiful documentation repositories, fun open source projects, organize meetups, or create the next revolutionary social app.
However, there is a reason that so many large startups start to lean on Java once they reach scale. Java is fast, encourages good design, and is great for large development teams.
The JVM is extremely fast and optimized. We handle many thousands of requests a second on a few VPSes.
The problem is that web startups tend to want to develop things quickly and be able to pivot quickly and easily. Java is not best at those things.
I know Java and worked with it for years. I do all of my startup coding in Lisp. Java forces you to do a lot of things that may make your code more reliable and easier for others to use, but it comes at the cost of being less productive, and in startups, being able to develop quickly is extremely important. That is why languages like Lisp or Ruby or Python are much more popular in the startup world.
That said, we have been at it for 5 years now, so it would be a stretch to call us a startup, but we use Java for 90% of our platform codebase, with Ruby acting as a glue.
which is not to say it's bad. it's actually really good, with lots of great qualities.
but compared to PHP, Ruby and Python, it's rather verbose. As a general rule you can pound out way more feature points per hour in a less verbose language than a more verbose one.
there are other factors, sure, but I think this is the biggest one.
Verbosity doesn't equal less productivity. I would be really surprised if anyone here said their bottleneck in programming was the speed they can type.
Also, all languages have their needless verbosity - look at 'end' vs '}' (ruby vs java). Which is the more verbose?
Java doesn't abstract very well beyond objects and classes. This becomes pretty irritating in stuff like event handlers, where you'd really like to use something like a lambda/delegate, but the only option you have is an inner class. This might change in the future, but right now some minor language features would make it much easier, and you'd avoid hard to track down annotations and reflection.
Also, Java library design often tends towards the obfuscated. [...]Adapters, [...]Implementations and [...]Factories, the usually bloated read/write beans, checked exceptions…
Having said that, there are lots of really good libraries and frameworks who don't fall into those traps (well, at last not too deeply). And maybe Oracle will bestow onto us some sparkly new bits that will cut down on some boiler plate and will alleviate the need for IDE wizards/code generators or stuff like lombok[1]. In some areas, languages like Perl, Python (or even Lisp) will still have advantages, but it would be nice if Java programmers could at least catch up a little to C#.
[1]: http://projectlombok.org/
I've been using Java for 10 years+, and never used any of that.
If you just avoid all the enterprisey crap, Java is a very nice place to be.
Disagree. And not based on myth. Based on direct experience over 25 years doing programming. Verbosity -- holding all other things equal -- does equal less productivity.
To put the argument in thumbnail form: it takes about the same amount of time for me to devise a programming design for something in Python as in Java. But to type in, run and test that design? Much less time with Python than Java. The human is the bottleneck at development time, in general, not the computer, not the runtime execution speed. I also only have a finite amount of display screen real estate, so with a more concise language I can "see" more feature points on the screen, all at once, when looking at source code. And since there are less LOC if I ever have to do code surgery or cut-and-paste things around I can do that faster too, in general, with a more concise language. But all arguments aside -- because they are irrelevant in the face of direct experience -- I can say that I now personally avoid choosing Java in all the personal projects I've initiated, and I also bias to advising startups to avoid it (in general) in favor of a lighter language. The issue is more complex when you're dealing with an external client and somebody else's business, however, because sometimes the benefits of Java outweigh it's verbosity -- and there's nothing wrong with choosing it if those factors are critical and pertinent to any particular project.
But when a design is clear, and my implementation choices are clear and fresh in my head, and I know almost exactly what LOC I'm going to write next, then yes I've found that "new line creation speed" does impact the overall time it's going to take to finish a particular feature or change. Years and years of observations backing this up.
Well, around 20 years here.
If you look at the extreme. Regular expressions. They're concise to the extreme. That has distinct disadvantages.
So clearly verbosity!=bad.I started with basic but quickly moved on to creating large programs in assembly. I think once you've done that for a few years you start to look past the lines of code and more into general program structure and flow.
'public static final' isn't verbose. They're keywords. They're flags. They're not meaningful program structure, so your brain skips over them unless it needs to check what the flags are.
People often mistake keywords like the above for verbosity. The actual syntax of java code, eg {}(). etc is very concise.