Comment by jaredcwhite | Hacker News Reader

Comment by jaredcwhite | Hacker News Reader

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.

>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?

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

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

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

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

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.

Reply on news.ycombinator.com