I just realized your joke about Meteor. Forgot it’s a full stack framework. No, thanks. I’m sticking with Phoenix 
Red
1
StefanHoutzager
Read about the “franken-stack” http://www.east5th.co/blog/2016/08/15/meteor-in-front-phoenix-in-back-part-1/
2
Red
brightball
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
Red
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
StefanHoutzager
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.” (The State of JavaScript in 2015 | Jimmy Breck-McKye)
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
sudostack
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
4
Red
Morganjackson
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
OvermindDL1
Keeping brunch is honestly a better idea. It will compress, minimize, and optimize the little javascript that you may have, as well as doing the same with your CSS and potentially more.
0