Foundation?

[leonelgalan]

Should we add Foundation?

Issues we had in the past:

• Hard to to keep granular imports up-to-date. When not using @import "foundation" and reporting individual files instead (See https://github.com/zurb/foundation-rails/blob/5b89403bca4f08854ebf458bfe240194a3ed66a6/vendor/assets/stylesheets/foundation.scss). I want FE to import only the files they need.
• Misuse of Foundation: Variables aren't changed, a lot of code is copy pasted.

As an alternative we could use something like: Bourbon, Neat, Bitters and Refills.

[reedlaw]

Personally, I'd like to see a complete separation between front end and back end code. Rails' asset pipeline has been nothing but a source of frustration from the beginning. Why don't we write clean interfaces that output simple data structures and then let front enders choose whatever build tools and frameworks they want? If we have to render something to get the app running, why not handlebars templates that can then be reused by the front end? Let gulp or grunt handle front end builds. Let it even be a separate repo with its own test suite. Then there is no confusion on where bugs lie and clean separation of concerns.

[joeyjoejoejr]

I'm with reed on this. I'd actually like to see our default build without any of the asset pipeline or preprocessing gems at all, and more tools like active_model_serializers, and a api document generator. Let's let the front end decide what they'd like to use.

So my vote is by default no asset pipeline, no slim, no coffescript, no sass, etc. To be honest even if they have me do full stack work on a future project, I'll probably push to have separate repos and a clean separation and use a client-side framework for the front end.

[reedlaw]

Complete separation of business logic and delivery mechanism (web) is going to take some experimenting and learning, but I think in the long run it will be worth it. I have an app generator that removes Sprockets and assets. The way I see it is the backend Rails app returns only plain data objects that can be used by the front end application. JSON would be the clear format choice. As a fallback, Rails can render handlebars templates on the backend. But do we even bother making our apps gracefully degrade for disabled javascript anymore? I would venture that virtually none of our apps can work 100% without javascript enabled. If all our Rails app does is render JSON, the front end app could be a single page javascript app or it could have one template for each controller action.

Front end apps could be written with dummy test JSON. They can get started even before the back end is ready. The dummy JSON can be generated with Faker-style data to test the layout. There should be a test suite that checks if extremely long strings cause layout failures (perhaps by screen capture/comparison). Ideally, there should be a way to document each use case with example data structures that are then referenced by both front end and back end.

[joeyjoejoejr]

I haven't sat down to write it, but I've been mulling over an idea to capture and mock out requests to the JSON backend from a javascript app (using a JS equivalent to VCR) and then use that data to run test cases against the rails app. You could disable it to test the whole system end to end or keep it enabled and test just the front-end or just the backend.

[leonelgalan]

I believe is a "Gold standard" for Rails developers, but I don't think it should be a default, it's too far from the "Rails Way" and it has a steep learning curve. Maybe an option allows us to generate projects this way.

• Separation of concerns can be achieved rendering views within Rails, it just requires discipline.
• A lot of the benefits of "convention" are lost by this separation, we would be requiring the FE to write a lot of code to replace things like the: asset pipeline, authentication (think Devise).
• Deploying from two projects has to be more complex

[joeyjoejoejr]

I agree with you that it is significantly different than the "Rails Way" and might have a bit of a steeper learning curve, but I don't think it's too far off. I think it's very close to how they are doing weaveup right now. And if weaveup is any example I doubt we are going to see another standard server-generated website at SB

I'd like to address a couple of your points:

• Separation of concerns can be achieved with rendering views in rails. To me saying that something can be done right the old way if you have discipline is a bit of a "process smell" in my opinion. We should be striving to a point where the right way is the easy way. We all lack discipline sometimes, and I've rarely seen rails views that didn't suffer from it.
• I'm not sure what conventions are lost. I can see your point on authentication, but devise offers out of the box token authentication. As far as the asset pipeline goes, FE wouldn't have to write an extra line of code to deal with that. There are much better build tools in the javascript ecosystem and I'm certain they already use them. Grunt, Gulp, Broccoli, Bower, etc.
• Deploying is marginally more complex, but can usually be achieved by a number of methods. In the past I've done it all with nginx. You serve the rails server as normal and you serve the FE files like you would a static site. Each deploys to their own location separately. If you have CORS set up, they can be on completely separate servers.

[reedlaw]

@joeyjoejoejr interesting idea. On the rails side, that could provide a useful intergration test, although much of it should already be covered by unit tests. It would mostly test the controllers and routes. For the front end side, I'm not sure how to best test interactions/POST requests, but maybe a small Sinatra or node app would work. Although I'd hate to have the duplication that entails.

@leonelgalan I wouldn't call it a standard, more like an ideal for developers who value separation of concerns (a category which unfortunately doesn't include DHH). To answer your points:

• True, if absolutely no logic is allowed in views. It's far too easy to cheat with erb to show/hide UI elements. Ideally role-based views would be compositions made up of lots of tiny templates with no logic.
• What would FE miss about the asset pipeline? If they are familiar with node-based tools they should be thrilled to be able to continue to use those tools instead of searching for compatible gems (with names like font-awesome-sass-rails). FE should not need an authentication library to write a front end app. They should just be parsing JSON data like { current_user: { type: 'guest' } } which would render a 'user_nav/guest' template or { current_user: { type: 'employee', first_name: 'reed' } } which would render 'user_nav/employee' with {{first_name}}.
• True, but it enables front end changes without a unicorn restart and speeds up rails deploys because it doesn't have to compile assets on the server.

[joeyjoejoejr]

Also, what @reedlaw said.

[joeyjoejoejr]

@reedlaw Yeah. It would just give general integration for both ends without having to have the whole stack running and would ensure that the interfaces stayed in synch. I think for the post requests, you would just mock the response you expect. Ideally, I wouldn't want to run a server at all. I really haven't gotten down to details yet though.

[BrandonMathis]

What % of SB apps are developed with a heavy front-end framework like Angular?

[leonelgalan]

The way is proposed here, together with Rails as an API, 0%. That's why I'm open to make it an option, but we are far from making that jump. On Aug 8, 2014 9:20 AM, "BrandonMathis" notifications@github.com wrote:

What % of SB apps are developed with a heavy front-end framework like Angular?

— Reply to this email directly or view it on GitHub https://github.com/smashingboxes/box_cutter/issues/7#issuecomment-51598768 .

[crfrazier]

Not sure but design wants to move in that direction; we've had that conversation many times. Raleigh likes the idea of making sites feel more like apps.

On Fri, Aug 8, 2014 at 9:20 AM, BrandonMathis notifications@github.com wrote:

What % of SB apps are developed with a heavy front-end framework like Angular?

— Reply to this email directly or view it on GitHub https://github.com/smashingboxes/box_cutter/issues/7#issuecomment-51598768 .

[image: Smashing Boxes] http://smashingboxes.com/

Carolyn Frazier Senior Project Manager Smashing Boxes

p. 336-403-8447 e. carolyn@smashingboxes.com biko@smashingboxes.com w. smashingboxes.com

[joeyjoejoejr]

Yeah, to be honest, I'm really not opposed to making this an option. I just see that more and more of our apps will move toward this separation, especially with iOS and android apps already needing an API it will make sense to have webapps take advantage of the same api.

[RickCarlino]

I hear Grape mounts nicely on Rails apps in cases where it is used as an API.

[reedlaw]

I just found out about another approach to separating backend and frontend concerns. It uses Node+Reactjs to implement views-as-a-service over HTTP. The example uses a PHP app for the backend but it should be easy to do the same thing with a Rails app. The javascript code is "isomorphic" so it's write once--you don't have to write separate code for both node and react--and it runs on either the server or the client making it search engine friendly.

[elfassy]

i think there are two categories of websites:

1) Marketing / Forms websites As far as i know, Google's bots don't use javascript thus your SEO is hurt if you don't have an html fallback. Also form building is supper efficient with the rails helpers and gems (simple_form).

2) Web Apps Weaveup would fall under this category. These are apps that require some interaction with the user that is outside of standard form. For this category a JS framework with a rails api might be beneficial.

I think these are not mutually exclusive. You can think of an app that is more Marketing pre-login and App post-login. I'd be ok with using the two together. The asset pipeline can be used to compile everything together. In terms of learning curve, there is a large learning curve to get FE to use Rails helpers and Rails AJAX correctly. I think they might prefer to stay in the land of JS, where they are more familiar.

Back to the topic of Foundation. I'd like to see more components like Refills. These can be created for a specific project but reused on any. One thing to keep in mind with Neat is that it uses SASS and likely doesn't work with JS frameworks...

[ethikz]

Speaking for FE mostly, we love the idea of decoupling FE and BE. Biko is currently working a build tool for the FE to help decouple.

As far as Foundation goes, I do not agree with using any of these type of frameworks like Foundation, Bourbon or Neat. Since we are supporting more modern browsers by default we can move to flexbox which will handle the grids mostly. If we must use a grid the general consensus has been to use Jeet.gs!.

If we are to use Rails apps I have added a PR for the common gems that FE will utilize in the Gemfile which includes linters, etc. It can be ignored but we are opposed to using any FE framework.

With that said if anything FE related needs to be added then it should be from what's inside my PR.

[elfassy]

Moved FE / BE discussion here https://github.com/smashingboxes/box_cutter/issues/21