Is JavaScript framework necessary for frontend?

I’m developing a Phoenix application with a simple read/write functionality. All my friends insist that I should write only backend in Phoenix, but use one of the JavaScript frameworks for the front end (meteor, react, etc.) Should I follow their advice? The only reason I don’t want to mess with JavaScript is because I don’t know it well enough, which will set me back significantly. Plus, each framework has it’s own syntax I need learn in addition. So 1 month project will easily become 3-6 months project.

2 Likes

Are there any specific requirements that can only be satisfied by using one?

1 Like

And ‘what’ are you making? How front-end heavy is it? Is it highly dynamic? Is it static? Etc…?

1 Like

Actually, there are no hard requirements. My client just want to test the idea if it’s worth doing. I was going to develop something quick and dirty, and then refactor if I need to.

It’s a fashion news website similar to Hacker News. Users can submit various posts about fashion industry, celebrities, etc., and then discuss them.

It will sure work fine will not be as refined though (no on the fly validations, page reloads etc.) but as MVP to test the waters it can work (provided your client is fine with limitations ).

2 Likes

@andre1sk So you would still recommend to rewrite the frontend with JavaScript later on because it provides better experience?

If you want to provide optimal user experience at least in the form of client side form validations it’s hard to get away from using js.

2 Likes

That makes sense. Could you recommend a framework that fits my project the best? Or any will do? My top 3 list:

  1. Meteor
  2. Riot
  3. VueJS

I would strongly recommend against Meteor :slight_smile:
You don’t have to build an SPA so simple jquery might be enough depending on you project needs.
Riot is fun (never used in a production project though) but if you are going to dedicate a lot of effort to learning js and a framework one of the big three might be a better investment of your time React (not a framework but…), Angular(2) or Ember.

4 Likes

Thanks! Scratching out Meteor off my list. Forgot about good-old jQuery. That should be enough to keep me going.

I just realized your joke about Meteor. Forgot it’s a full stack framework. No, thanks. I’m sticking with Phoenix :slight_smile:

1 Like

Read about the “franken-stack” :slight_smile: http://www.east5th.co/blog/2016/08/15/meteor-in-front-phoenix-in-back-part-1/

2 Likes

Very interesting :smile:

No. The inclusion of JavaScript frameworks in every decision is one of the worst programming trends I’ve seen in my career. It’s completely unnecessary unless you are building something that actually needs to be a single page app that will stay open for a while.

Most sites are “open, check, close” experiences that don’t come close to justifying the additional overhead.

7 Likes

Thanks @brightball. I follow that approach every time I start a new project. My rule of thumb is to stay away from the javascript until it’s really needed. For most of my projects, jQuery calls are enough to do what I needed.

2 Likes

Maybe twitter bootstrap then, for a quick test? In general I do not prefer to use large frameworks. Copy paste some things I wrote / copy pasted in the past about it:
“Prefer dedicated libraries to monolithic frameworks. When you choose a framework, you make a large, long term committment. You sign up to learn about the framework’s various inner workings and strange behaviours. You also sign up to a period of ineffectiveness whilst you’re getting to grips with things. If the framework turns out to be the wrong bet, you lose a lot. But if you pick and choose from libraries, you can afford to replace one part of your front end stack
whilst retaining the rest.”
“There will never be a perfect framework so you can just hack the most relevant features together. By using small libraries - components with a dedicated purpose and a small surface area - it becomes possible to pick and mix, to swap parts of our front end stack out if and when they are superceded. New projects can replace only the parts that matter, whilst core functionality whose designs are settled - routing APIs, say - can stay exactly the same between the years.” (http://www.breck-mckye.com/blog/2014/12/the-state-of-javascript-in-2015/)
If you wrap the libs they will be replacable with minimal effort. All in all a lot of work, you have to see for yourself if it could return the investment. I created a dynamic grid this way (see pic). Responsive design, mininimal config of the UI in the .html. I was rewriting the framework (not working at it now) so that it could take all UI definitions (except styling) in a json provided by the server which makes the ui even more flexible / dynamic (adaptable on the fly based on userproperties, f.e. language).

1 Like

You mentioned a “Hacker News”-like fashion portal. I think you’ll be just fine with server-side rendering. Are you familiar with Rails? If so, this is simple and straight forward in Phoenix. Each action maps to an eex template. Like some others have mentioned before, there’s nothing wrong with using just jQuery and introducing a client-side library or framework later. If you go the jQuery route, you can probably omit Brunch, $ mix phoenix.new --no-brunch. Happy hacking :slight_smile:

4 Likes

It sounds like omitting Brunch is good idea in my case. Thanks, @sudostack.

I think what you need is something like instantclick or barbajs

Instaclick takes 5 minutes to get up and running and is very effective if all you want is near instant page transitions.

Barbajs is also very easy to setup but it comes with a lot more options so you will have to spend some more time learning what it can do for you.

2 Likes