Lotus, a web framework for Ruby | Hacker News Reader

Lotus, a web framework for Ruby

lucaguidi.com

285 pointskrasnoukhov135 comments

This is depressingly similar to what I was aiming for when I recently began work on: https://github.com/lean-framework/lean (I feel like this happens to me a lot.)

Rails controllers are hard to test because actions aren't designed to be testable objects.

ActiveRecord models become monolithic because there's no separation of instantiation, validation, persistence, or retrieval.

I originally experimented with building a Rails app that forgoes ActiveRecord to a large extent; using plain Ruby classes + Virtus gem to separate the aforementioned concerns depending on context.

I was pretty satisfied with the number of design headaches I was able to avoid, which is when I started to create a framework around the aforementioned paradigms.

Not sure if I just lost my motivation or not, but I'm glad I'm not alone.

Maybe you just found your kindred spirit and can join forces and produce something awesome for all of us

I'd be OK with that.

> This is depressingly similar

In graduate school, many a moon ago, my advisor would say that this is validation of the idea, so one should be happy to be on the right track.

Thanks for the de-demotivation.

I don't see it as such. I see it as "independently arriving at the same, correct solution." This is vision, not just skill. You don't see a lot of that. You probably just got distracted by another, harder problem once you realized you could see the end of the project.

It isn't zero sum. There's still substantial design space to explore.

Lotus being received well just means people are ready for the idea. That may not have been the case in 2011, for instance.

I think I was misunderstood. By de-demotivation I meant re-motivation :)

I seem to recall, a while back the creator of RVM suffered a similarly disheartening setback when rbenv came out. RVM is still going strong. The community has not decided on lightweight frameworks. The choices you make won't be the same as lotus. You will no doubt attract a group of like-minded people who will be grateful for your contributions.

This is a promising start. I've felt for a while now that we need some strong alternatives to Rails for the folks who feel like the Rails Way and the Ruby Way don't always get along.

It still feels a bit DSL-centric from the examples I've seen thus far, and haven't dug into things to see what the generated Ruby looks like -- but if it's anything close to simple, this is something that has a chance to become an important part of the Ruby ecosystem.

If nothing else, it's great to see things like this because they provide concrete example code for discussions that (IMHO) need to happen.

I've felt for a while now that we need some strong alternatives to Rails for the folks who feel like the Rails Way and the Ruby Way don't always get along.

This is why I prefer to use Ramaze. It feels more natural if you're already used to coding in Ruby. It also supports the evolution of development from lightweight to complex sites without having to switch frameworks.

http://ramaze.net

For a while, I thought Sinatra was taking that role? It might be interesting to think about what people are looking for that's neither Sinatra nor Rails, or why Sinatra didn't live up to what people were hoping (if people think that).

Sometimes I think some of this is just utopian grass-is-greener thinking. While there are _many_ things I'd do differently in Rails if I had the choice (some but certainly not all of which the Rails core team probably agrees with, if they had the chance to start over)...

...I think some of the "the thing we need is something _lighter weight_ than Rails" thinking is basically wishful thinking. When you start with something lighter weight, you (being me) generally find you need more than it offers, and then you've got to go finding your own things to do those things, and when these extra third party things end up not as high quality as you'd like, or end up abandoned by their developers, or you end up spending many hours re-inventing a wheel you're sure someone else has already invented.... either the 'lighter thing' ends up gaining weight, or you end up wishing it had.

Doesn't mean I agree with all of Rails choices about what to include, or how to architect it. But I think people under-estimate how challenging it is to hit the sweet spots, as if Rails core team just lacked the will or intelligence or proper understanding or something, none of which I think they lack. Still, certainly alternatives are great, testing grounds for other possible ways of doing things are great, the more different things we see, the better all of our architecting and coding gets, that's the only way to learn.

Sinatra, in my opinion, gets pretty hacked together after the initial `def get '/'; puts "Hello World"; end`

Personally, I think Camping is the perfect fit for Ruby frameworks

It is very possible to organize a Sinatra project elegantly. It generally involves a combination of require_relative and Dir.glob().

That's interesting; I tend to agree with the crowd that wishes Rails didn't do any kind of auto-loading.

But are you suggesting that you need to add a kind of basic auto-loading to Sinatra to keep things sane?

Rails autoloading "just happens". If you're doing explicitly require/require_relative, even on the results of Dir.glob(), the application explicitly specifies what will be loaded, and when. For my part I find that much cleaner.

Another way is to add a file, say init.rb, to a directory and require_relative that. It achieves the same thing, of course.

Only if you treat it as a framework. Sinatra is a great library.

For any project worth talking about Sinatra is too skinny. Basically you have to hack your routing in about the same way you do with Node's Express, enumerating the bindings between routes and methods. Obviously there are clever ways to do it but you end up reimplementing the resourceful routes of Rails.

Another problem is that you really want to use ActiveRecord to access the database. Anything else it too painful. So you end up creating AR models and you have to manually include them.

Finally there are views. I won't even enter into that.

Soon you end up with a worse engineered Rails. I've been using Sinatra only for serving API requests for small projects. I won't touch it for anything else.

I've built large projects with Sinatra. I've done the same with Rails, many times. The idea that you can't build something substantial with Sinatra is hogwash.

It is not a given that Active Record -- I presume you mean the pattern -- is necessary, but AR is available in Sequel, which is the usual choice of ORM when build with Sinatra. (In addition, Sequel has myriad additional benefits over Rails' ActiveRecord, particularly if you want to use raw SQL.)

Views in Sinatra are not much different to Rails, so whatever issue you have, I'm unclear what they are.

If you end up engineering a worse Rails then, as they say, you are doing it wrong.

As I mentioned, I use both, and you can achieve the same results with either. They are both, in effect, rack stacks these days; they simply have different conventions, one more opinionated than the other.

One of the problems with always doing things the 'Rails Way' is that people start thinking there are no other ways. Plenty of people build significant apps with rich and engaging interfaces with much lighter frameworks than Sinatra even.

Sinatra is the perfect REST API server language for a client application. Given the way apps are going these days, I'm not sure why everyone isn't building single-page web apps that put 90% of the responsibility on the client and use only simple JSON communications with the server for persistence or authentication.

Rails is a pile of conventions. What I want isn't something more lightweight, it's something heavyweight with different conventions.

Try Padrino http://padrinorb.com

Looks nice. I particularly like the ORM, which seems well-designed compared to ActiveRecord.

That said, I have a distinct feeling this is too little, too late. I and my teams have long migrated away from frameworks, to microservices, or what some people call SOA, and we are not looking back. I strongly encourage this design over the old monolithic Rails approach.

These are mostly small, highly specialized Sinatra backends that speak data only through REST APIs. For such backends, you don't need views, and you hardly need models; when "deconstructing" your data model into multiple backends, the data model for each microservice often becomes absurdly simple. Mostly you need a simple way to express REST endpoints. Sinatra is very simple and doesn't support any abstraction, but that's mostly a good thing. And you can split your API across multiple files easily. The backends are getting so simple that it's starting to look very tempting to migrate to Go, where we could get real performance and concurrency.

On the front end, I would still use Sinatra if it were a classic app -- you can cobble together a "railsy" app with Sinatra by picking your template system, database layer and so on -- but mostly these days we build Node.js single-page apps that are sewn together with NPM and Browserify. Web app development has never been as simple and elegant as it is when done this way.

Can you give done examples of the types of things these micro services do?

+1, I would love to take a look at an example or two, as this sounds very interesting.

Not the poster, but I've written a few small sinatra-endpoints in my time.

For example I wrote a self-hosted comment-system, which is like a very basic disqus service. The back-end is a simple sinatra service that just allows "GET /comments" and "POST comments". (http://github.com/skx/e-comments/)

Last week I wrote a webhook-consumer, again using Sinatra. It receives a POST from github, parses the received JSON, and adds some details of the body into a queue for later processing.

Both services allow simple deployment and total may 50 lines of code each.

Sounds very similar to the things I've done with web.py in Python-land. Very small, lightweight services that had no need for the power of Django. One such example was a GET/POST/DELETE service to vote on submitted items (ideas, in this case).

Sure. I have been thinking about writing up a blog post about our work since it may be of use to others. A quick summary of some of our current microservices:

- Single sign-on. We have a service that abstracts users into identities that map to one or more actual logins. It facilitates the OAuth interaction with providers. To add login in any app, you just redirect the browser to the microservice's /auth/:provider API; it redirects through FB or whatever.

- For sites that don't want to rely on providers like FB, we also have a simple OAuth provider that has a basic user database with salted passwords, email/password management, etc.

- Data store. We have a structured, hierarchical document-oriented data store that is a thin layer on top of PostgreSQL. Most apps don't have their own database, but use this data store.

- Security. We have a common, path-based security model across apps that can be validated through calls into a central security microservice; it's mostly a registry of what apps delegate responsibility, and when you ask the security service about whether, say, you're allowed to modify the object at path acmecorp.blogapp.posts.1, it asks every app that is registered to be the authority for that path. For example, acmecorp.blogapp might use a role-based security system, but a different path exampleinc.cmsapp might use LDAP.

- Voting. For Reddit-style voting and kudos we have a small microservice.

- Search. We wrap our data store in an indexing system that uses ElasticSearch.

- Organizational management. We have a microservice that handles members, groups and their roles. It plugs into the security system so that we can delegate access to very precise parts of the system. For example, any user can see comments, only the author can edit a comment, and editors can update anything.

- Email/texting. We have a microservice that abstracts text and email, currently supporting things like Mailgun and Twilio. It allows us to swap out the implementation without the app knowing.

- GIS/map stuff. We have a separate microservices for geocoding and storing GIS features.

- Image/audio/video processing. We have a wrapper around ffmpeg and other tools that processes transcoding requests.

An important piece of the system is the extensive use of pub/sub via RabbitMQ exchanges to asynchronously publish and listen to events. For example, any microservice can listen to changes to any part of the data store (based on path or event). For example, our search microservice automatically populates ElasticSearch with content from the data store.

Lastly, every app has a microservice as its own backend; for example, if the app is a blog system, we have a frontend (eg., a Node.js desktop/mobile web UI), and a separate backend tailored to that frontend; the frontend treats the backend like any other microservice.

Thanks, this is really useful in comparison to my experiences. It all makes a lot of sense to me except the data store. Is the data store supposed to replace all direct database use by other services?

Not at all. We have apps that have their own private data stores either because they need complicated models with many inter-model connections, or because their data is completely private to themselves, and there is absolutely no benefit to a sharing it through an API.

The data store is intended primarily to be used for hetereogenous "content collections", for the lack of a better terms -- blog posts, comments, classified listings, products, articles, events, messages, etc. Anything that exists in bulk with simple CRUD semantics. It's less suitable for structural objects such as sites, users, groups, memberships, hierarchical, etc. where the semantics need to go beyond CRUD.

The data store model is extremely simple, and therefore somewhat poor in terms of possible interactions. There is very limited support for querying, for example, and no support for transactions. It essentially a slight step up from a key-value store. Interactions that require complicated queries need to go through other services such as ElasticSearch.

But there are benefits. One is that many apps simply don't need very complicated schemas. Another is that this sort of model forces you to optimize the schema in such a way that you avoid complicated joins. Thirdly, it's easy to integrate with a security system. Overall, it's just stupidly simple to get started. No setup, just start posting stuff.

However, we do see the need for a richer data store. A colleague mine is developing a new data store that is optimized for graph-like structures (probably layered on top of OrientDB), which may end up being a replacement for the current store because content can also benefit from being graph-like; blog posts have authors, for example. Another thing we have noticed is that the lack of schema validation leads to discrepancies, and it would be good to have this.

This sounds very interesting. Please make a blog post about this if time permits. We seriously lack good resources about micro services when it comes to Ruby.

The ORM part, largely due to the repository pattern, is very similar to my earlier attempt - Datamappify - https://github.com/fredwu/datamappify

Given time, effort and popularity, I could see Lotus::Model to become the de facto alternative to ActiveRecord, overtaking the ROM (Ruby Object Mapper, previously known as DataMapper) project. :)

I think it's great to see someone make a run at a more decoupled ruby web app approach. I hope it succeeds.

In my experience working on Obvious (http://obvious.retromocha.com) it is hard to get Ruby developers behind decoupled architectures because the large majority aren't Ruby devs, they are Rails devs and Rails happens to be in Ruby.

Also, the larger group of developers doesn't like the idea of an app being a giant collection of very small objects. It's like there is a gravity to the notion of objects where we think of an object as something akin to a car, not the thousands of parts that make up a car.

Last, I think the idea of MVC doesn't place the appropriate number of objects for the different roles in normal request processing. At a reasonable point of complexity really end up with routes, controllers, entities, data access objects or repositories/adaptors, presenters, views, templates, helpers, utilities/libs, and probably some other bits of random code in there somehow. That doesn't fit the 3 role view of the world that is MVC.

Lotus does a better job than most of addressing such things, but I think the MVC approach in general falls flat.

That lack of appropriate roles means that as programmers we invent a lot of names, patterns, roles, etc. to fit what our code actually ends up doing. That's why you see a lot of service patterns, presenter patterns, etc. being attached to Rails. Everybody is duct taping their approach to the notion of MVC, but very few are saying "what if we didn't see request processing as only having 3 roles?"

MVC is better and cleaner than writing a page as one giant PHP file maybe, but I've seen it fall down so many times that I no longer trust it as a useful pattern or abstraction for expressing request processing and HTML string manipulation in code.

In fact, if we were building command line apps and writing to files, I don't think we would use MVC at all. But, since we're writing strings of HTML, it's totally different right?

I'm pretty sure they make a pill or something for that scorching case of hasheritis. ;)

One problem I have with "decoupled" architectures is that the only way you can sensibly interop with everything from RDBMS to flat JSON files is if you treat the RDBMS as a flat file. For instance, the sample Twitter clone treats every available DB as a plain key-value store.

> One problem I have with "decoupled" architectures is that the only way you can sensibly interop with everything from RDBMS to flat JSON files is if you treat the RDBMS as a flat file.

The Repository pattern is what you're looking for.

This is an interesting attempt. It has Sinatra like simplicity, providing the modular architecture that was promised with the Merb + Rails merger.

At the very least, this will spark some interesting conversations and ideas.

By what I've seen I like the spirit of Lotus, but I sense a movement away from complete web frameworks to pure API back-ends with the emergence of great single page JS frameworks like Ember. One ruby one that I like is https://intridea.github.io/grape/. One interesting node API framework I mean to try is http://loopback.io/.

You could easily use Lotus as an API server.

That's a trend indeed (and personally I like it pretty much).

But lotus has a view component that allows you to do stuff """just like rails""" (many quotes intended). That's the beauty of it: it's modular and not opinionated, so you can pick an mix the tools you want to compose in order to suffice your needs.

Yeah, lotus looks like it could do a good job at letting you share/extend models and other bits of code between a Rails-like html server and a pure api server. Maybe those two things are the same server, different modules in the same server, or different servers sharing libraries. Choice is up to you since lotus looks like it can cleanly do both.

Yes, I also think that the future of backend development is micro services communicating over defined HTTP API endpoints or other message protocols.

If you look closely, rendering presentation layer on the server side and then sending it to the client is a hack and we've been doing it for a long time. It's time for changes.

Single page web apps are broken for a lot of the most important purposes that the worlds largest and most important web-apps need to fulfill. For example how could Wikipedia function as a single page app since it wouldn't be consumable by screen readers and robots of various shapes and sizes ? That's just one example, but there are many. What about the semantic web ? microformats anyone ?

Google isn't the only search engine out there so the fact that you can use a crutch to let google crawl your site doesn't fix the problem.

https://en.wikipedia.org/wiki/Semantic_Web http://www.w3.org/standards/semanticweb/

> If you look closely, rendering presentation layer on the server side and then sending it to the client is a hack and we've been doing it for a long time. It's time for changes.

From the view/presentation layer's perspective, it shouldn't matter where the rendering happens, and as a programmer working on these systems I'm tired of baking assumptions about the data layer into the view layer.

I actually think there's a best-of-both-worlds solution that we'll converge on at some point, which is this:

We have the option of rendering in both locations with the same code.

This allows the initial render to be offloaded to the server (so that the app's initial state is totally established and can be sent along with the app itself in a single HTTP request), and then subsequent rendering updates could happen mostly client-side (fetching only the raw data from the server where necessary).

This allows the JS-everywhere crowd to build their entire app as if all logic is running in-browser (with only a basic API on the server), but it appeases the more old-fashioned developers who want to be able to construct mappings between URLs and actual HTML documents (that don't have to be spun up and re-constructed using client-side scripting). There's obviously a huge debate here as to whether or not the latter is worth it, but I'd say it would be nice if only so that I don't need to have a flash of unloaded content or a "loading" indicator before the app is ready to be used.

I also don't like having to use PhantomJS to scrape data from a website that could very easily consist of HTML documents instead of a blob of JS, but that's probably not enough to affect most people's opinions.

I'm all for new frameworks that emphasize different ideas and philosophies. If nobody ever tried experimenting with a new approach, we wouldn't have Rails in the first place. So kudos to Luca and his fine work in developing Lotus. I like much of what I see.

That being said, I feel like YARWF (Yet Another Ruby Web Framework) is not the most pressing matter in the web space today, and I take exception to the notion that this is a complete web framework. It's not. A complete web framework has client-side components that facilitate two-way communication to/from the server, data binding, HTML5 history state-based page/view swapping, etc. In other words, the type of stuff being addressed by Angular, etc. At this point I wouldn't even characterize Rails itself as a "complete web framework"...it's proven itself to be incomplete and needs something more to be added to it for this kind of stuff.

What's the solution? Well, most people in the Ruby world do the typical route of a Ruby + Rails/whatever backend and a JS-based (or CoffeeScript-based) frontend. But I don't like it. I want one language that works on both sides and in fact allows OOP code sharing between the two.

That's why I'm so bullish on Opal (http://opalrb.org) -- Ruby-to-JS compiler. It may not be perfect, but it's usable and it's here now. What we need is a framework built on top of Opal that is to the client what Rails, or Lotus, is to the server. Then I think we can safely say that we have a complete web framework solution for Ruby. Until then...not quite.

You say "A complete web framework has client-side components", but you don't consider there are action based frameworks and component based frameworks. They follow different approaches. Lotus is action based.

You are forgetting that not all people are building thick-client applications.

> I want one language that works on both sides and in fact allows OOP code sharing between the two.

I think, having one language in both frontend and backend does not work in long run, regardless of your preferred language of choice.

we love ruby and yet where I work - we actively maintain Ruby, Python, Javascript and Java applications. Besides, I find it too hard to write OOP code which is reusable within same problem domain, writing OOP code that crosses the concerns between backend and frontend sounds like inviting lot of problems and lot of useless discussion on - which code goes where.

EDIT: I didn't mean business agnostic code can't be shared between frontend and backend btw. Date parsing, uri parsing etc are examples of such libraries. But overall aiming to write business code that can be shared between frontend and backend is problematic.

there are some great frameworks that do do one language everywhere (my top choices would be om and hoplon from the clojurescript camp, and opa from the custom language camp). there is something to be said for being able to seamlessly pass data around between the frontend and backend, and letting the language and framework handle the low-level details for you.

I've always thought this would be nice, but whenever I actually design the theoretical code that would use this, the savings is much less than I would have thought. Real world actualities like security and privacy can either remove many of your gains or, if you ignore them, leave you with what I'd consider a buggy website.

This can happen with knockout and other libraries when you end up dumping data into an object to send over simply to render it view side. You end up with a lot of wires between your controller and the view template rendered on the client side.

>A complete web framework has client-side components that facilitate two-way communication to/from the server, data binding, HTML5 history state-based page/view swapping, etc. In other words, the type of stuff being addressed by Angular, etc.

No. I can't possibly disagree with this any more strongly.

I'm probably on the wrong side of history here, but Javascript absolutely should _not_ be a requirement for using a website. If your website doesn't work with NoScript turned on, I won't utilize it. Full stop.

In my mind Javascript should be used for progressive enhancement for those users that opt to enable it (or I suppose more correctly: choose not to disable it). Building a thick client web app is the fastest route to ensuring I won't use it.

You are welcome to hold that opinion. Just keep in mind that the majority of users don't even know what javascript is or how to disable it. Depending on the audience, the fact that you don't want to enable javascript may or may not be a concern to the developers.

>If your website doesn't work with NoScript turned on, I won't utilize it.

You're definitely in the minority then, most users don't even know what javascript is let alone NoScript. I find it ridiculous that people are arguing against javascript, we're using a computer and not allowing it to run code.

I was, and am, mostly on the side that argues that client-side javascript support can be assumed to such a degree that it can safely be considered requirement in a lot of cases.

However, I do have some reservations of a more 'ideological' nature when it comes to requiring javascript when it isn't strictly necessary.

I still believe one of the most powerful things about the web is the (relative) simplicity of the request/response server-side-rendering approach. There are so many ways in which a web page can be consumed (scraped, read-later-tools, etc.), within 'fair' boundaries of course. And this often falls apart because of client-side javascript.

This is fine when it concerns a web-app that is specifically made for browsers (where ideally there's also a public-facing API). But for most other things it should not be necessary, and I believe it harms the possibilities of the open web. And quite often I find that it deceases the usability in general (back-button breakage, etc.).

Of course, my ideal solution is both server- and client-side support, used appropriately, through something like React or PhantomJS.

I'd be curious what you think of this: http://platform.qbix.com/guide/pages

we're using a computer and not allowing it to run code.

...from sources which some people find uncomfortable to be blindly trusting. From a security perspective, it's a huge attack vector - the majority of browser exploits require JS to work. Even if it's sandboxed, there's also the annoyance aspect; scripts can consume CPU and do all sorts of irritating things like breaking the back button and seizure-inducing animations.

> seizure-inducing animations

You don't need JavaScript for that.

    div {
      animation: seizure 16.6ms infinite alternate;
    }
    
    @keyframes seizure {
      0%   { background: black; }
      100% { background: white; }
    }

I respect your opinion, but I will happily disregard it when it comes to building web apps. If that means I someday lose you as a customer, so be it.

Hear, hear!

You are fighting a losing battle.

I suspect that many sites simply do not have staff and/or resources capable of producing NoScript-friendly (degradable) work.

Producing NoScript-friendly work is, oddly, ridiculously easy. You write your "view" code for React.JS, and render this via node.js on the server, then have the client do exactly the same. You can pick up libraries - or write your own in half an hour - which implement the glue to talk to models from both the client and the server.

You shouldn't even need to write your business logic in node.js if it doesn't fit the language well, just write an RPC server in whatever language you prefer.

I've never seen a coherent argument against progressive enhancement on served HTML.

I used to think like you, but I've since understood since that this is the wrong battle. You have 2 things that are more and more diverging yet use the same platform for distribution:

- websites as-you-know-them, which goal is to provide _information_

- webapps, which goal is to provide _services_

Your point of view is completely valid for the first kind: when you want the information, you don't want the frills that go around it. You want clear pointers to it in the form of clean URLs. You want it to be accessible on your smartphone that doesn't run javascript because it's heavy and has wildly different inputs.

But the second kind is completely different. When you (as in the general you) are using GMail, you actually want to use an application to manage your mail, possibly send and receive them. Whether it's in your chrome browser or native in your OS matters only as far as how easy it is to install, and on that point the web has won. But it's just a happy accident of how things have evolved.

You are not against javascript per se, you are against web apps in general. Which is totally understandable, because there are better ways to provide services on a computer than using a shiny HTML+CSS+Javascript interpreter that fetches programs on-the-fly and can't even do half of what a real OS can do.

Similarly, I find myself wandering lost and confused in the valley between "app" and "document". I've been doing front-end "app" stuff a few years now, mostly because I wanted to write JS and thought that servers were scary and complex. But now that I've mostly gotten over that, I look at requirements and user stories and ask: could this just be done with HTML forms? (Sure, so maybe we want some animation and fine-grained interactivity, but most of the time these could just be frosting on the HTTP cake.)

I guess some things are really "documents" (Wikipedia articles) and some things are really "apps" (HTML5 games), but it seems like there's a huge swath of uncritical groupthink that's saying you're web thing needs to be an "app" because iPhone.

I couldn't care less about losing you as a visitor to my site. It's 2014. JavaScript is required for using the web.

JavaScript is required to read any article? Why?

The apps that I work on require JavaScript, but the landing pages for these apps do not. The content sites that I've worked on also don't require JavaScript.

Not once in my life have I been reading an article on the web when I said to myself, "Man, this article sure could use some JavaScript."

Not once in my life have I ever considered switching off JavaScript. How completely silly.

It's not "completely" silly at all. For "normal" users, it's true that they may never need to do this. It's also a largely "safe" assumption that your site's visitors will have JavaScript enabled.

However there are security concerns when dealing with JavaScript. For example, if you've ever surfed the darknet, disabling JavaScript is highly recommended to avoid present and future exploits that could compromise your anonymity, funds, etc.

I think the turning point is already ahead of us where the thin client server-heavy webservices will be considered a "smell" or at least the uncanonical way of developing web apps.

It pays off to do a lot in the client (good libraries provided). You have a high frequency of development iterations, direct response during development and you are working closely to the "medium" of presentation.

I have had a project that started out as a flask web app and all of the sudden, I realized that moving things to the JavaScript world in the client (I was using ClojureScript there) was actually safer, faster and better than keeping it on the server. In the end the server Did validation and database access in the sense of a Web API. It really was a clean solution

What is your aversion to javascript? As a client-side scripting language, it enables us to deliver, much, much richer UX to the end user. It should not be put aside as just for 'progressive enhancement'. That's ridiculous. This comment wins my nomination for most backward of the year on HN.

Because for all the tech progression in the last 20 years, a javascript heavy page is still really slow to load and use if you have more than a few tabs open.

Look, I'm all for progressive-enhancement driven development where it makes sense. But there are (many, many) websites where it doesn't make sense nowadays.

> If your website doesn't work with NoScript turned on, I won't utilize it. Full stop.

I take it you don't use Youtube? Even for the parts of the web that do work without javascript, enabling js usually offers an enormous improvement in usability. I don't want to reload the page every time I upvote someone on Hacker News for example.

While I don't believe there's a canonical definition of what constitutes a complete web framework, I do agree with your main point though; things like data two-way communication and data-binding shouldn't be a prerequisite for qualification as such. That would imply that 'complete web frameworks' didn't exist before 2011 or so.

Some might say you were on the wrong side of history.. If they even knew where the line got to. I doubt anybody has seen it in the past 5 years, so who is to say?

Vienna is a Ruby web front-end framework that looks promising. https://github.com/opal/vienna

> A complete web framework has client-side components that facilitate two-way communication to/from the server, data binding, HTML5 history state-based page/view swapping, etc. In other words, the type of stuff being addressed by Angular, etc. <

What you describe sounds very much like Plato's shadows (search for "Allegory of the Cave") when compared to a native application.

Web browsers aren't operating systems. They weren't and still aren't designed to be general application execution environments.

To me the examples look too wordy compared to sinatra or padrino. Like the lack of auto loading though, the autoloading is my opinion a huge mistake in rails and padrino.

Whenever I hear lightweight and complete, I always wonder if they handle one of the hardest things to do cleanly in web-apps: user authentication and access control of resources. Does Lotus support this out of the box?

A quick look at the API[1] showed a couple mentions of Sessions in the example structure. Not sure if it is handled out of the box, but I get the impression it is not difficult to implement. But that is just authentication, no idea about access control.

[1] http://rdoc.info/gems/lotusrb

It doesn't. It's only the base, but a well constructed base.

It doesn't, nor is supposed to. It is composed of small parts with as little responsibility as possible. The idea of Lotus is to not force you to use any tool or favor any kind of approach to such things, but instead give you enough "frame work" to compose with other tools that are responsible for such tasks like authorization, authentication, persistence, or really any kind of stuff you need to do.

Slightly OT, but as a mobile guy who occasionally toys with server-side programming, authentication is always where I get stuck. I'd like to see some examples of how to implement authentication and sessions cleanly without too much framework magic. Any pointers?

Rolling your own? This is as simple as it gets: http://128bitstudios.com/2011/11/21/authentication-with-sina...

If you want to make it even easier, use OmniAuth: http://recipes.sinatrarb.com/p/middleware/twitter_authentica...

Feels like Merb all over again!

Data Mapper, significantly less code, humble core-contributor.

Great work!

I really liked Merb, and stuck by it for some time. Rails 3 was supposed to be Merb 2. It wasn't really, but Merb was still lost to the "merge".

Is it weird / bad karma to call this "Lotus"?

You could make an example application called "Notes" with Lotus.

Or a spreadsheet and call it "123"...

Or even worse - a webmail app called "cc:Mail".

Considering that IBM owns the trademark for "Lotus" for software products, I suspect there will an issue with that at some point.

Lotus::View is the first library for Ruby that marks a separation between view objects and templates.

This is a great idea, but Lotus::View isn't the first. See Mustache.rb, for example.

https://github.com/defunkt/mustache

At the moment, if I should switch from Rails to another Ruby framework, the killer feature would be a well integrated built-in streaming support (something like Lotus::Live in this case), which nowadays is a must for a web framework; otherwise the stability of Rails and the big community around it (people, gems) would win against this project, as against the many other current Ruby frameworks.

Anyway I wish good luck for this project, which was created by a person of the same country of mine (Italy), of the same city (Rome) and which I met at the only Ruby meeting ever done in Rome I suppose, a couple of years ago.

stop complaining and start a Rome Ruby meetup group. I did that couple of months ago with Ruby Zagreb meetup group. Europe, and especially eastern Europe needs more meetup groups!

I wasn't complaining about it, I just reminded when I met him. I don't feel the missing of meetups, I prefer internet communities (mailing lists, GitHub, HN...)

Rails has http://api.rubyonrails.org/classes/ActionController/Streamin... which I never used. It seems that Lotus::Live isn't ready yet. I can't find any docs for it so I don't know how they compare. Could you point me to an URL. Thanks.

Yes, but ActionController::Streaming is not made for long pooling; what I mean is 1) web sockets and/or server side events support and 2) Raisl streaming helpers (models watching, client events, etc.); essentially, the good parts of node.js frameworks.

Lotus::Live doesn't exist, it is a name example for the feature of which I feel the missing.

Weird, I get the idea of defining a new web framework API, but why would you build everything from scratch? There's loads of very good open source code out there.

Why not fork DataMapper for Lotus::Model for example? Now you have some dodgy hand rolled library that's probably not seen enough eyes to be really production proof.

Lotus::Model apparently depends on https://github.com/jeremyevans/sequel , which has been widely used in production similarly to DataMapper.

It seems you are right, my apologies, I clearly hadn't read deep enough. Still, Sequel is just an SQL abstraction. DataMapper is exactly what Lotus::Model is, a full model abstraction over databases, regardless of the querying language.

Some years ago I even implemented an XQuery querying backend for DataMapper, it was not much work at all, at a time where AR still had SQL code all through the base and Sequel was just in low profile development.

> It seems you are right, my apologies, I clearly hadn't read deep enough. Still, Sequel is just an SQL abstraction. DataMapper is exactly what Lotus::Model is, a full model abstraction over databases, regardless of the querying language.

AFAICT from reading the Sequel code (and especially the code for the existing adapters), there's no real hard dependency on SQL (since the adapter both generates and applies the query string), though there is a dependency on being able to map back and forth to SQL-like operations.

It shouldn't be impossible to write a driver for a non-SQL backend for Sequel, though it seems like it would be progressively harder the farther from the assumptions common to SQL its operation was.

Correct, it's not impossible, there was a proof of concept mongo driver: https://github.com/jeremyevans/sequel-mongo . I doubt it still works with current Sequel, though, as I only coded it for a lightning talk in 2010.

Sequel is way more actively supported/developed compared to datamapper. Last release of DM was in 13/10/2011...

It's not a choice between DataMapper and Sequel, they are not comparable. Anyway, I know it's not maintained anymore, that's why I suggested forking it.

Sequel, (and Sequel::Model) is an absolute peach. The best ORM I've ever used.

EDIT: Lotus::Model barely seems to use Sequel. Maybe I missed it...

Note that DataMapper does not implement the DataMapper pattern but the ActiveRecord pattern. Lotus::Model appear to aim to implement the DataMapper pattern. They're fundamentally different.

Thank for great fw.

I'm by no mean a Ruby expert but finding Sinatra is so simple to create complex apps, and Rails is so complex atm to pick up. I'm making slowly progress in Rails and always not sure if I done thing correctly in Rails way.

Lotus seems small enough, and good enouh, balance between Sinatra and Rails for me.

Keep up the good work. Thanks.

http://www.padrinorb.com/ check it out

This is so cool. Built on top of Sinatra. So I can consider it like chaplin to backbone, right? It creates an architecture on top of original framework.

My feeling is the same.

sinatra is more powerful than you maybe have realize..

balance between Sinatra and Rails for me.

Ramaze is that sweet-spot for me.

http://ramaze.net

Thank you for such a great link. It is also well-maintain. last commit was 2 months ago. Its base is small enough to understand for me too. I like to understand more Ruby by reading the code. However, Rails was so big to me. Thanks again.

I'm intrigued. Just signed up for the mailing list. Do you have any links to applications built in Lotus?

Here is a simple gist from Lotus author: https://gist.github.com/jodosha/9830002

And also there is a WIP room reservation app: https://github.com/sidonath/room-reservation

Just found another example app: https://github.com/joneslee85/lotus-blog

There aren't many applications using the solution as a whole - as it was just made public recenltly, but you can check some example applications used for tests in the lotus repo: https://github.com/lotus/lotus/tree/master/test/fixtures/

"We have infinite combinations. Small components have enormous advantadges in terms of reusability."

Typo: "advantages". Nitpicking, I know, but it's in the first bolded sentence on the page and it detracts from your messaging.

Cool project, good luck! :)

Additional nitpick: "fewer" instead of "less", as in

"... you employ fewer DSLs and ..."

This is a textbook example trademark infringement. IBM will not be humored.

uhhhhhh, I don't know if that's true.

Lotus was never a ruby web application framework. Guess Apple's going to have to change the name of Swift because of that other programming language, amirite?

> Lotus was never a ruby web application framework.

A trademark's domain is nowhere near that specific. Recall that Apple was sued by Apple Records because it made devices capable of being used "in the record business".

> Guess Apple's going to have to change the name of Swift because of that other programming language, amirite?

Interesting that you say this. Apple certainly has a history of trademarking its languages. Apple has trademarks on Objective-C and on AppleScript. Its trademark on Dylan was abandoned and its trademark on Hypertalk was cancelled. I'm guessing that Apple hasn't trademarked Swift because it can't: there are two many other items already named Swift in the area. And the Swift scripting language is hardly a threat to them: it's an NSF-funded research effort.

sinatra/base, rack-urlmap and sequel, why would you want more fluff?

It looks like you're missing the point. As an example, I've built the adapter for DynamoDB[1] so you can throw sequel out in matter of minutes even for existing app, and most likely without any code change.

[1] https://github.com/krasnoukhov/lotus-dynamodb

No, if I choose Sequel (http://sequel.jeremyevans.net) I want to use all the power it gives me, not some lowest common denominator.. Also not all projects needs models, you know, there's other data access patterns..

the concept of a model is not at all tied to a data access pattern unless you subscribe to model = ActiveRecord::Base inheritor in the Rails world.

Model is a well-defined term in the domain-driven design world, as in "Domain Model"

The presence of Lotus::Model was a red flag to me, until I realised that Lotus doesn't seem to depend on it being used? I don't want my web framework to dictate my model API.

Lotus::Model may be great, and I like that it's actually trying to implement the DataMapper pattern, but there are projects where all the model code was written for the backend and we only later decided to expose it as a web API for example, and switching to another model layer would be out of the question.

You might want to emphasise more strongly that these components can (assuming I'm right) be mixed and matched with other components like Sequel if you prefer, since the naming sort-of hints that it's all tied together.

@vidarh Lotus doesn't depend on Lotus::Model. I kept it out from the dependencies because of the reasons that you've described. Future versions of Lotus will have some facilities for Model, but it won't be a requirement.

EDIT: BTW Lotus::Model is shipped with an SQL adapter that is a nicer wrapper on top of Sequel. If you love this library you will love Lotus::Model too.

"We have infinite combinations. Small components have enormous advantadges in terms of reusability."

Typo: advantages.

Just a nit, but it does stand out since it's in the first bolded sentence on the page.

Isn't this old, i know i have heard of it several years ago.

It is rather interesting that most parts of Lotus has been posted on HN every months, and yet dont even get more then 10 comment and a few points, not to mention it was never on the HN frontpage.

Now all of a sudden it has 241 point. 134 comment.

How many of this type of frameworks we had. Padrino was there to fix something but achieved nothing. It is better to focus on rails and fixing rails rather than start a framework for everything.

Few doge years ago sinatra was faster than rails, today... not so obvious and still offering much smaller set of functionality.

> It is better to focus on rails and fixing rails

For many of us "fixing Rails" is easiest achieved by starting from scratch.

> and still offering much smaller set of functionality.

... and that is why I prefer Sinatra to Rails.

> For many of us "fixing Rails" is easiest achieved by starting from scratch.

See, e.g., the road to Rails 3 through Merb.

Theres a bit of politics that get in the way of "fixing rails". Mainly, many things that others consider anti patterns, DHH and other maintainers are fine with.

Reply on news.ycombinator.com