6 ms·
Does the author have any experience with anything but Ember? How interactive are their interfaces? How does the person responsible for UX feel about only using
by 5trokerac3 9y ago
Does the author have any experience with anything but Ember? How interactive are their interfaces? How does the person responsible for UX feel about only using server-side rendering? Did he/she just do a crappy frontend implementation and is now falling back to a fixed mindset rationalization?
- MattBearman 9y agoI feel like I answered most of these questions on the post, but anyway: 1 - I've tried a number of frameworks, although ember is the only one I've used extensively. As I said, the issue was mostly with the thick client / thin backend api set up rather than specific ember stuff, with the exception of ember being overly opinionated. 2 - not interactive enough to require a js framework 3 - BugMuncher is just me, so I'm also the UX guy and I think server side rendering is awesome 4 - no (in my own humble opinion)
- 5trokerac3 9y agoI've found there's a correlation between expertise in a given technology stack and the gravitas given to complaints about that stack. Having built with all the methods mentioned in the article, I couldn't imagine building a modern web application without a framework (my current preference being Angular 4). I was recently able to package an entire 30+ view application into a single 650k bundle with webpack. If you tie that kind of app to bare minimum microservices, running off of well planned DB and caching schemas (that can power any interface imaginable), then having to go back to the server for every single micro-view doesn't make sense. This is doubled... tripled if you think about the effect on mobile page load speed from anything but the best connections. My point being, it might make more sense to exhaust every avenue and refine your own development skills before writing a generalized, negative leaning blog post on your company's site.
- tmikaeld 9y agoJust wanted to ask about 3: Why is server-side rendering awesome? I've only found that: 1. It consumes a lot of server CPU that's of limited capacity 2. It's often slower than rendering on the client (Since the client usually isn't under load) 3. You loose interactivity in the browser because you have to reload the whole DOM on every new page
- SomeHacker44 9y agoHe said he was using Rails. Rails has the ability not to do #3. Google "Turbolinks".
- tmikaeld 9y agoSince I've never used Rails, I've never heard of it before. Have to say, that's quite impressive :)
- boubiyeah 9y agoWell frontend frameworks are useless if you don't have much interaction :p