An excellent piece. The only problem is that it is now 2015, and everybody's moving to Websocket-based backends. Without WS support, new web frameworks are quite doomed.
Web sockets isn't the be all and end all tech. There's still a place for server rendered, simple pages. Not every web app needs to be a single page app.
That's not what they said. Not every web app needs to be a single page app, that's true but it's a non sequitur.
The point was that if a new framework aims to capture enough attention and traction to be a sustainable alternative to the incumbents it has to support websocket .
>Why does a framework have to carry features only needed in edge cases?
Because most apps are being built in the conditions of uncertainty and the development team doesn't know if the edge case will become a business requirement.
>Feature bloat/mission creep sucks.
Unqualified, this statement is nothing more than a thought terminating cliche. Whatever constitutes "bloat" depends on the context and preferences of a decision maker.
>Whatever constitutes "bloat" depends on the context and preferences of a decision maker.
Same goes for whatever constitutes a necessity. I seriously challenge the idea that "websockets" are a must have.
Case in point, their lack haven't prevented tons of PHP, Ruby, Python, etc frameworks (all the tons of them that are not async/event based and can't handle websockets well if at all), from succeeding.
Heck, 1/4 of the web is based on Wordpress (including players like CNN, Forbes, Sony, and NYT blogs) and that doesn't even touch websockets, not to mention not being a proper CMS/framework in lots of other ways.
>prevented tons of PHP, Ruby, Python,etc frameworks
Django is adding websockets support using the $150K grant from Mozilla. Rails is adding websockets support in the next version with ActionCable. Phoenix and Play frameworks have great support for websockets. Websockets are an integral part of node ecosystem.
Your websockets "challenge" is not based on facts.
>Django is adding websockets support using the $150K grant from Mozilla. Rails is adding websockets support in the next version with ActionCable.
Note the future tense. By which time Rapidoid might or might not have them as well.
>Your websockets "challenge" is not based on facts.
No challenge at all. Just plain old reality. Most successful frameworks don't support websockets at the moment, and are still widely used.
The fact that Node and some Java frameworks do (as does Python with Tornado and co) doesn't change that fact. Note also how I never said there don't exist frameworks that DO support websockets, so I don't get why you mention these to me.
For me, it is. I get nearly instantaneous reaction times for UI events, even where round-trip to server is involved (WS session is already created, so no duplicated headers, etc.) Additionally, especially for mobile apps, if connection is dropped, it is immediately detectable and it can go to offline mode right away.
For webapps, certainly. You'd get much responsive UI, as there is much less overhead in responding to events, which improves end-user experience. Public APIs should stay REST, perhaps.
I don't see any negative aspects of exposing the same REST API through WebSockets internally. Public API (if exists) doesn't need to change, private API loses the redundant transfer of headers and cookies.
How did they manage to write a fast optimized web server?
Lots of people have done so, if you have the skills and determination. It also helps if you focus on that, instead of completeness, like Netty probably does.
dsl-json looks like an interesting tool.
" DSL compiler requires Mono/.NET, but only during compilation. There is no runtime Mono/.NET dependency, only JVM. "
The performance optimization is based on:
- using off-heap input and output buffers,
- minimizing the number of objects that are created when parsing the input and generating the output,
- using object pools to reuse the objects that must be created,
- using thread-local helper data structures on the I/O threads to avoid synchronization and object instantiation.
What happens when you have a long database query running? Is it async (which is a bit impossible with JDBC) but does it block one of the threads in worker pool?
But the leader of the recent Java web frameworks really seem to be Vert.x ( http://vertx.io/ ) which I have started to use recently and like a lot so far.
Which is not that surprising since Vert.x is more than just a web framework. It also let's you build distributed applications and to scale your web app horizontally.
On another note, JAX-RS (a Java API for RESTful API's) is also fairly no-bullshit. It is also mature by now, and is supported by about a dozen implementations, including Jersey, WebLogic and JBoss.
This looks awesome! I used to use Spark for quick Java web apps, but I will (probably) try Rapidoid next time. That said, I have been using mostly Sinatra (Ruby) and Yesod (Haskell) recently but Rapidoid looks like a winner for Java-land.
I am surprised that I hadn't heard of Rapidoid before. +1 to HN
61 comments
[ 3.0 ms ] story [ 67.0 ms ] threadThe point was that if a new framework aims to capture enough attention and traction to be a sustainable alternative to the incumbents it has to support websocket .
The only part I think where websockets enable truly new functionality is displaying of live data and push notifications.
Feature bloat/mission creep sucks.
Because most apps are being built in the conditions of uncertainty and the development team doesn't know if the edge case will become a business requirement.
>Feature bloat/mission creep sucks.
Unqualified, this statement is nothing more than a thought terminating cliche. Whatever constitutes "bloat" depends on the context and preferences of a decision maker.
Same goes for whatever constitutes a necessity. I seriously challenge the idea that "websockets" are a must have.
Case in point, their lack haven't prevented tons of PHP, Ruby, Python, etc frameworks (all the tons of them that are not async/event based and can't handle websockets well if at all), from succeeding.
Heck, 1/4 of the web is based on Wordpress (including players like CNN, Forbes, Sony, and NYT blogs) and that doesn't even touch websockets, not to mention not being a proper CMS/framework in lots of other ways.
Django is adding websockets support using the $150K grant from Mozilla. Rails is adding websockets support in the next version with ActionCable. Phoenix and Play frameworks have great support for websockets. Websockets are an integral part of node ecosystem.
Your websockets "challenge" is not based on facts.
Note the future tense. By which time Rapidoid might or might not have them as well.
>Your websockets "challenge" is not based on facts.
No challenge at all. Just plain old reality. Most successful frameworks don't support websockets at the moment, and are still widely used.
The fact that Node and some Java frameworks do (as does Python with Tornado and co) doesn't change that fact. Note also how I never said there don't exist frameworks that DO support websockets, so I don't get why you mention these to me.
The part about knowing when the connection has dropped is actually really interesting...
You'd really be surprised. Not everybody moves or even has a use case for a websocket-based backend.
Lots of people have done so, if you have the skills and determination. It also helps if you focus on that, instead of completeness, like Netty probably does.
Is this because it allows the GC to be avoided, or because it allows value types to be emulated?
(Netty is well-optimized, but quite bloated as well).
The performance optimization is based on: - using off-heap input and output buffers, - minimizing the number of objects that are created when parsing the input and generating the output, - using object pools to reuse the objects that must be created, - using thread-local helper data structures on the I/O threads to avoid synchronization and object instantiation.
Rapidoid reminds me a little bit the Spark Framework (not Apache Spark, very unlucky name, though) which I use for fast prototyping and services.
http://sparkjava.com/
http://jooby.org/
http://www.ninjaframework.org/
But the leader of the recent Java web frameworks really seem to be Vert.x ( http://vertx.io/ ) which I have started to use recently and like a lot so far.
Love the easy, clean API - it's great for a reasonably sized project.
Github link https://github.com/rapidoid/rapidoid
I am surprised that I hadn't heard of Rapidoid before. +1 to HN
You also forgot to mention what I need to import in order to have the "On" object.
Maybe you can include something like this template on your getting started page.
Also needed would be a sample pom.xml file. I had a problem with java compiler version being older and unable to complie lambdas.My sample pom.xml (feel free to use it if you like) is:
Then I can run the test service using:I totally agree a tutorial like this is needed, and I am going to add such documentation soon...
If you have to recompile every time you change something, you're going to have a baaad time.