Congratulations on curating the JSF course.
I am keen to learn about modern Java web app front ends but this fear has been holding me back, what's your thoughts?
JSF2 added native AJAX support (prior to that you had to do it yourself or use a third-party tag library).
But for non-form activities, JSF is not a "greedy" framework, and you can mix it with other frameworks. I've used Apache CXF for ReST services, the Spring Framework and when I need other types of processing, I'll add in an appropriate subsystem for that.
JSF, however, was originally intended to be an abstract form framework. It assumed that the default infrastructure would be HTTP and HTML, but allows for plug-in replacement renderers in the event that some other infrastructure would be convenient. For example, before smartphones, there was a simplified display standard called WML that many of the web-capable but less powerful phones would use.
The Request/Response restriction is because that's how HTTP was originally designed. JSF itself operates in a pretty pure Model/View/Controller mode.
Having said that, I don't think that HTML5 support is yet baked into the JSF standard, and there's no native support for "fractured" HTTP (conversational/long-term connections).
Tim Holloway wrote:Having said that, I don't think that HTML5 support is yet baked into the JSF standard, and there's no native support for "fractured" HTTP (conversational/long-term connections).
One of the new features of JSF 2.2 (which was released in 2013) was support for HTML5, but that mainly has to do with the way you write Facelets pages. JSF 2.2 optionally lets you use HTML5 tags instead of JSF component tags, which is useful if you want to use HTML5-specific features. The pass-through elements and attributes tag libraries are useful for this.
This is not meant to rain on anyone's parade -- especially not Jesper's promotion week -- but I think you will find that this is prevalent throughout the industry. Most organizations pursuing modern web development will view "creating UI on the server" as hopelessly antiquated and passé.
I got laid off last October, and if all I had had to offer was my extensive experience with server-side UI technologies, and not also an extensive portfolio of front-end experience, I'd likely still be looking for a job.
There will likely always be some organizations using JEE technologies, but in my experience that's not where the focus of modern web development is, and is certainly not where it's going.
The current managerial mindset is all about "get it done quick and get it done cheap". Virtually nothing in Enterprise Java is either quick or cheap.
The darling frameworks of the day are all about presentation - getting something visible where the management and users can See Something Soon. They're mostly appearance-oriented, mixed with scripting languages that allow fast coding. Largely because they don't have strong type checking. Languages such as Java won't even let you compile until you've got the details in agreement. Scripting languages allow bad scripts to get all the way into production (quickly), where they lay in wait like serpents in the grass ready to strike at the worst moment.
A truly industrial-grade application is more than just a pretty face. People won't remember how fast you got the demo site up when the daily news is all about how your entire customer database ended up in Bulgaria. Or got shredded when the holiday rush began. A well-crafted app requires both good looks and good functionality. And it's a rare individual who's both artistically talented and also can make the gears grind finely.
Unfortunately, looks are all that really get judged and the "less is more" mindset so prevalent these days means that both the visual and functional parts of the app are usually handed to the same person. And, if they're lucky, they'll also get to be the sysadmin, network administrator and DBA.
I am myself more a back-end specialist than a front-end specialist.
Tim Holloway wrote:The current managerial mindset is all about "get it done quick and get it done cheap". Virtually nothing in Enterprise Java is either quick or cheap.
The darling frameworks of the day are all about presentation - getting something visible where the management and users can See Something Soon. They're mostly appearance-oriented, mixed with scripting languages that allow fast coding.
This seems to imply that those of us working in modern front-end development are all doing so in a slipshod manner. Far from it. Front-end development is just as hard, perhaps even more so, as backend development. Sure, either can be done in either a slipshod manner, or in a well-engineered manner. The choice of frameworks and tools is irrelevant to the care and level of engineering brought to a project.
The advantage of scripting platforms is that you can produce "something" quickly. Where something is defined as visible results. Strongly-typed languages will refuse to let you see anything until you have satisfied the type constraints enough to get clean compiles. Which, among other things weeds out bad assignments of incompatible data types. Weakly-typed languages often allow you the ability to throw random text into a file because until that file is actually invoked in the app, nothing is parsed (depending on the implementation). So you can end up with files with "Fill me in later", appalling fresher mistakes (and I've seen some appalling fresher mistakes come from people with 10 years experience - in mainframe assembly language!), or, like I said, random trash/filesystem corruption.
A dedicated quality-oriented programmer, of course, is going to push back, but when everyone's working in constant fear of "rightsizing", most can only push so much, and locally people privately complain about what they're being forced to do.
I observed quite a few years ago that a professional-quality software system is going to take about the same amount of time and work, regardless of what what language and platform you use. But professional system development falls into stages: design, coding, debugging, testing. Strongly-typed languages load the time spent into the design and coding phases. scripting languages permit you to spend less time on rigorous design and coding, but if you do, you'll pay for it in increased debugging time. Testing has always been shortchanged around here, alas.
I'm not against scripted languages per se. Not everything demands the full infrastructure. I've done my share of PHP and I'm doing a lot of Python these days. But I do get offended when I'm accused of "not being productive" because I'm trying to produce quality and I'm working with a platform that won't show pretty pictures until fairly late in the cycle.