from flask import Flask
app = Flask(__name__)
@app.route('/')
def hello_world():
return 'Hello World!'
if __name__ == '__main__':
app.run()
Of course, you still need to know how Python Does Things, and The Thousand Ways To Deploy An App, and Package Management and so on, but for this trivial example it's a lot more conceptually lean than the semi-equivalent offered above. I don't need to know about `Bootstrap<Configuration>` or a `JModernConfiguration`.
It's fair to point out that there will be a corresponding text file or option somewhere else, but…
Like I said above, "Granted, this may be easier with newer frameworks, but still." :). Good to see it's you can have some lighter loads.
TFA mentioned this was how Modern Java Web Dev With Instrumentation is Done (worth mentioning that Javaland instrumentation is world class), so just going by the examples he provided.
I think that is more a difference in which frameworks you use as opposed to which language. The examples in the article are using individual components to build out the system. This provides unlimited flexibility and will be very valuable if the system is going to scale in complexity.
My example on the other hand uses Spark, a micro framework that is not very flexible and hides a lot of the complexity, meaning that if your own solution becomes more complex you may have to abandon Spark entirely.
I've seen that dichotomy in every web framework I've encountered.
>I think that is more a difference in which frameworks you use as opposed to which language.
I don't think it has much to do with which language per se but more to do with what the language community considers acceptable. You can write mostly head-ache free frameworks filled with "magic" in Java like the rest of them, but it's not a strong cultural value.
To turn to the microframeworks example, I can't speak to Spark but in Ruby land it is not hard to flesh out your sinatra app into a more complex beast should the need arise - converting Sinatra half way to a mini Rails is not something I would recommend, but mostly because you lose easy-library support and ease-of-update down the road (you shouldn't be writing your own custom framework period, sort of thing), and not necessarily because of a lack of flexibility.
That's not much different here to the hello world in the article. Lets see...
You import some stuff... check.
You create an instance... check.
You define a route... check.
You define a method to implement the route... check.
You return a String... well the example returns a map, and converts it to JSON.
You start the app in a main method... check.
Sure the java is a little more wordy and there are some extra params which are not used (the IDE would fill those in automatically when you implement the interface), but the complexity is the just same as far as I can see.
Looking past shorter syntax and names, and a bit of magic to intuit the response content type, that's not a whole lot different from the code that gets Undertow spun up [1]. I suppose if you're worried about syntax and short names, Java is not right for you.
It's fair to point out that there will be a corresponding text file or option somewhere else, but…