Live data from Hacker News

Play framework for Java - a radical rethink of Java web app development?

playframework.org

41–50 of 103 posts

Re: Play framework for Java - a radical rethink of Java web app development?

#41
post #37
post #26

Earlier quoted context omitted.

Neither is an IPhone app, but I can guarantee you that most of the logic I use for my "Web Application" will be reused by my IPhone application. With the exception of my templating, work-flow and UI specific logic, so it begs the question why am I implementing my templating, workflow UI specific logic, in my "Web Application" (it's not reusable). Unless it really is a web UI to my enterprise application in which my U…

seo

http://googlewebmastercentral.blogspot.com/2009/10/proposal-...

Most people are already doing it.

Re: Play framework for Java - a radical rethink of Java web app development?

#42
Hmm, too much code in the template library, too much magic in general. I do like the general packacking, the automatic compilation and the snazzy error and testing interfaces. Seems a bit hard to change from their Groovy template system to something like StringTemplate, though.

Re: Play framework for Java - a radical rethink of Java web app development?

#43
post #29
post #11

Earlier quoted context omitted.

It seems to refer to this: > "Play is designed to operate in a ‘share nothing’ architecture. The idea is to keep the application completely stateless. By doing this you will allow your application to run on as many server nodes as needed at the same time. >What are the common traps you should avoid to keep the model stateless? Do not store any object on the Java heap for multiple requests" If that's all they're talki…

I haven't done any real dev with those frameworks you list so I'm wondering how do you manage session state? user profile, shopping cart, breadcrumbs, multi-request flows, etc... Do you write/read all that into the db/memcached for each request?

Yes. PHP does the same thing. Actually, most frameworks do that; very few keep state within the application server between requests. Statelessness, in that respect, improves scalability.

Re: Play framework for Java - a radical rethink of Java web app development?

#44
post #35
post #30

Earlier quoted context omitted.

No one said that they have to be micro services. One should provide composite services that provide all of the data for a work-flow. Then use a pub-sub event based model to notify the UI of available data. This way components stay loosely coupled and are only listening for an event that injects the relevant data that they need. This results in a single call to a composite service yet the micro services are available…

Building/maintaining that sounds way more complex than writing a JSP. In my experience, if you architect your server-side components well, if/when you want to expose something as a web service you can prop up a web service that's basically just a thin wrapper around the relevant backend component(s). It avoids the "premature optimization" of building everything as a bunch of micro and aggregate services that you may…

If you are a one man show maybe, but if you are a team it is far more maintainable because each concern is clearly delineated. JSP is not easier for a HTML designer nor is ASP or PHP it is an amalgamation of languages composites into a document. It is only easier for a code developer and that it the crux. Usually a company starts out as a one man shop with a code developer and then graduates to a team. Having to teach designers JSP is a waste of time and resources. The entrance barrier to web development is so high because of this bastardization of development domains. It is only easier because you are reasoning from your view point. To a new developer just learning HTML the list of technologies is insurmountable all because we coupled back end technologies with the front end.

Re: Play framework for Java - a radical rethink of Java web app development?

#46
post #26

Earlier quoted context omitted.

Neither is an IPhone app, but I can guarantee you that most of the logic I use for my "Web Application" will be reused by my IPhone application. With the exception of my templating, work-flow and UI specific logic, so it begs the question why am I implementing my templating, workflow UI specific logic, in my "Web Application" (it's not reusable). Unless it really is a web UI to my enterprise application in which my U…

Because this is a premature optimization. I've seen companies falling at the other extreme ... making the interface "totally" decoupled, so that they could replace the UI anytime they wanted. That's why monstrosities like XSLT appeared. But I haven't seen any example of a good application yet that does this successfully, because whether you like it or not, the web UI will require backend logic that your iPhone app do…

No XSLT was an attempt to make the UI generic, either you accept that UI are a custom tailored to be optimized for the platform or you accept the dumb terminal philosophy where you try to generalize the UI to adapt to all platforms.

The fact remains that human preference is for tailored UI and not until AJAX took hold was the desktops dominance as a platform threatened. Time and time again, tailored UI's are preferred. It is the reason for Apple's return to stardom as well as the rise of web 2.0.

Developers try to fight this mentality to work in their boxed solution and I understand it, but you have to clearly refute evidence to the contrary to believe that the user prefers application developed in this manner.

So If that is the case why not design an architecture that accounts for this reality and makes peoples jobs whose responsibility it is to assist the user instead of enforcing a developers domain on them.

As well, I do not agree that different UI's require different back end logic they require different work-flow logic and work-flow is not reusable. If they require different back end logic for say getCustomer, addCustomer, validateAddress then there is core architectural flaw in the solution. How a customer is then displayed is a problem for the UI e.g. Do I show all info in one screen do I show pivots to make room for more screen real-state.

It is not Apples fault, that is faulty logic, Apple is giving their users what they want and their last quarter clearly reflects that.

Web sites that rely on web services are not tricky to scale look at my document on amazon I referenced. It is essential to scaling. Google, Amazon et. al. are doing this precisely for that reason scalability and to not be locked into back-end or front end technologies. Not to mention you are distributing all work-flow and dynamic templating to the clients, which in practice has a large impact on resource utilization.

Re: Play framework for Java - a radical rethink of Java web app development?

#47
post #38
post #17

"The Play framework makes it easier to build Web applications with Java" Maybe you should not be building web applications with Java or C# or . Maybe you should be building web services with these languages and using AJAX, a client side toolkit, Javscript, HTML and CSS to build a UI that communicates with said services. Maybe this decouples your UI implementation from your business logic implementation so you can go…

Maybe you should just use what makes the job best for you?

That is a developer mindset and flawed at it's core. You should use what is easiest for the person that relies on your work to use.

Re: Play framework for Java - a radical rethink of Java web app development?

#49
How does the following work? Must be a preprocessing step, if I'm not mistaken.

With play, you can just write:

Article article = Article.findById(id); User user = User.getConnected(); render(article, user);

And retrieve objects from their Java local name in the template. That saves a lot of useless lines of code...

Re: Play framework for Java - a radical rethink of Java web app development?

#50
post #37
post #26

Earlier quoted context omitted.

Neither is an IPhone app, but I can guarantee you that most of the logic I use for my "Web Application" will be reused by my IPhone application. With the exception of my templating, work-flow and UI specific logic, so it begs the question why am I implementing my templating, workflow UI specific logic, in my "Web Application" (it's not reusable). Unless it really is a web UI to my enterprise application in which my U…

seo

... is a fantasy.
Post reply on HN