Live data from Hacker News

Lotus, a web framework for Ruby

lucaguidi.com

81–90 of 143 posts

Re: Lotus, a web framework for Ruby

#81
post #80

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.

Re: Lotus, a web framework for Ruby

#82

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 tha…

>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 we…

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.

Re: Lotus, a web framework for Ruby

#83

Earlier quoted context omitted.

>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 we…

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.

Re: Lotus, a web framework for Ruby

#84
post #41
post #20

Earlier quoted context omitted.

> 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 probl…

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.

[deleted]

Re: Lotus, a web framework for Ruby

#85
post #41
post #20

Earlier quoted context omitted.

> 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 probl…

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.

Re: Lotus, a web framework for Ruby

#86

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 import…

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.

Re: Lotus, a web framework for Ruby

#87
post #76

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.

Re: Lotus, a web framework for Ruby

#88

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 tha…

>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 we…

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.

Re: Lotus, a web framework for Ruby

#90
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.

Post reply on HN