81–90 of 150 posts
That font is ridiculously huge. It's painful to read. Looks like the browser's font resize functionality is blocked but you can change the size by resizing your browser width. I really don't like that UI pattern.
Earlier quoted context omitted.
Do you think RoR is a good choice when all you really want is a service with a REST API? I prototyped something in a couple of days with Python and Flask and it made a good enough impression that we are thinking about fully developing the idea. I'm open to just about any tech and am thinking about continuing with Flask (and Flask-restful), using Go, or Ruby on Rails. I have almost no experience with any of these and…
I’ve built rails api only applications for a long time and I find it to be a great experience. Now, to be fair, I pick it because I know Rails very well. But it’s worth taking a look at for sure.
Even if it is a little excessive (which I don't think it is), I have features planned in the future where having an ORM like ActiveRecord+Ruby will make things very simple.
For at _least_ 90% of the things out there, you don't need a front-end framework like React/Vue/Ember/Angular. And while these front-end frameworks increase the complexity of the app, its trade-off often doesn't nearly provide enough value in terms of speed/extensibility/maintainability to warrant it.
Rendering server-side views is fine: plug-in Turbolinks and have a blast. It's not cool, it won't get you stylepoints with your colleagues, but you should be trying to impress your client/boss with speed/extensibility/maintainability, and not impress with complexity of your stack.
> As developers, however, we usually care about > 1. isolated, reusable, testable code that is easy to reason > about; > 2. short “code change → visible result” cycle; > 3. straightforward dependency management; and > well-maintained tools. > Sure, “classic” Rails gives our code some structure: there > are separate folders for view templates, javascripts, > stylesheets and images. But as the front-end complexity > gr…
NPM is a well-maintained tool. Version 5 got major updates in speed and usability. They where aware of the Node release cycle and implemented the new version in advance so it would be rolled out alongside Node. NPM now does way faster caching than before, can lock dependencies in specific versions more easily (inspired by Yarn) and may have a flat dependency tree if your project demands it (like when using Polymer an…
Off-topic: That website sets font size in `vw` (viewport width percentage). This is horrible: Text is way too large on maximized desktop browsers, and zooming the page doesn't change that, but only causes a weird jump in position.
What's the purpose of making text small, punishing readers for not maximizing the site? :-)
Seriously, it could be a way to make text flow into a smaller column, but there is no need to make text smaller. HN reflows and keeps the same font size.
I built a rather extensive application for a client over the last 18 months using Rails API and Angular, using a number of these sorts of principles. While it is entirely possible to use what the article suggested, I argue it's a premature optimization and may be a detriment to the entire project. We're now actively removing the Angular portion of the project and going back to the good old way. I wouldn't say this de…
But yes, it's nice that the world is finally realizing Arc was way ahead of its time. HN is snappy because the HTML is small, with few network requests.
https://rauchg.com/2014/7-principles-of-rich-web-application...
I built a rather extensive application for a client over the last 18 months using Rails API and Angular, using a number of these sorts of principles. While it is entirely possible to use what the article suggested, I argue it's a premature optimization and may be a detriment to the entire project. We're now actively removing the Angular portion of the project and going back to the good old way. I wouldn't say this de…
That presentation makes me want to learn Rails but fortunately there is a shortcut, you can use turbolinks on its own (written in coffescript thought).
Honestly, as a Rails dev, this just seems more complicated than creating a Rails app in API mode and using #{React||Vue||Ember}} for the front-end. It's extremely easy to get started with a front-end app using vue-cli. This article spends a lot of time changing Rails' default functionality to achieve behavior similar to what vue-cli gives you by typing `vue init webpack` and answering a few questions. I understand th…
I've been working with Rails since 2006 and I'll create two separate projects. A Rails API project and a front end one. Two projects, two repositories, maybe two teams (specialized teams are more common than full stack.) The front end is served by the reverse proxy in front of Rails.
If I want to serve some semi-static HTML page from Rails, all I have to do is sharing the CSS file and create a controller for that (PagesController is a classic.) I don't think there are many chances of sharing HTML in a meaningful way among ERB and JSX, that must be duplicated.
Then Rails people will work with Rails tools and JavaScript people will work with the favorite tools of the month. The advantage is that if you want to onboard some pure front end developers they won't have to learn about Rails.