121–130 of 150 posts
Earlier quoted context omitted.
Of course! If you have human resource to separate and maintain backend and frontend - it's an excellent solution. But it's article not for teams like this. The described solution for full-stack developers and small projects, which needs to be maintainable too. And component manner is a proper way to organize frontend code.
I would split in two even if I'm working on it alone.
Earlier quoted context omitted.
I would split in two even if I'm working on it alone.
Ok. Let's see from another side on this point. If you are beginner Rails developer who doesn't know how to configure Webpack properly and doesn't know how to works with React/Vue/Ember? And if your project must be a SEO-friendly? You don't know React, Webpack and doesn't know how to works with React/Vue SSR. Maybe learning its tools will be an excellent investment if you want to be a front-end developer. But what if…
My project started more than four years ago. It was a mainly content project around content creating and sharing, and of course SEO.
Facebook released React two month early than we started. Webpack has not yet created. Gulp is a bleeding edge. And we used sprockets, CoffeeScript and SASS.
It's is a massive project now. And it changed development vector for last year. We make a lot of changes, and we haven't resourced for rewriting them on separated front-end and back-end for now.
But described methodology allows us to keep this project maintainable. We migrated this approach from Sprockets to Gulp, and from Gulp to Webpack.
And we thought. What if we tell about how we maintain the project to beginners? They are writing jQuery-spaghetti code, and they may don't know frontend frameworks and Webpack.
Let's tell them how to write maintainable code with webpacker, components, BEM and our code organization. It's maybe a good starting point for them.
Earlier quoted context omitted.
Thus creating cleaner, more focused, more testable, likely faster, and more maintainable code bases. Which also adhere to the Single-Responsibility Principle. We as developers already offload certain tasks to separate servers. Do you use your app server to terminate TLS connections? You could; but why would you when Nginx can do a much better job of it? You could store you application data like usernames and password…
More testable? Because they are discrete codebases, possibly. It sure sounds like getting a dev environment setup that mirrors the production env just got a lot harder. Given there is an entire new codebase there is now an overall larger coverage area to test. Faster? I don't see how putting an entire app server layer in between your HTTP requests is going to make anything faster. More maintainable? You now have an e…
This is factually wrong. You have a small component that mounts your front-end like a pure function. No loss in maintainability, no "duplicate" anything.
Earlier quoted context omitted.
Of course! If you have human resource to separate and maintain backend and frontend - it's an excellent solution. But it's article not for teams like this. The described solution for full-stack developers and small projects, which needs to be maintainable too. And component manner is a proper way to organize frontend code.
I would split in two even if I'm working on it alone.
Earlier quoted context omitted.
There really aren't any major benefits/downsides anymore regardless of what you'll read. To clear one thing up, you should compare Rails/Django/Sails (each language's "full" web framework), and Sinatra/Flask/Express (minimalist web frameworks). Each of the full frameworks offer a flavor or configuration of the framework that is focused to building RESTful APIs, and you can build the front end in whatever you want. Th…
> There really aren't any major benefits/downsides anymore regardless of what you'll read Who made you the grand arbiter? There are huge differences. Rails is miles ahead in the options you present. Probably 90% of startups that don't have a specific reason not to, use Rails - and rightly so. Rails has over 65k commits. Django has 25k. Sails? Less than 7k. Don't tell me these are equivalent.
Earlier quoted context omitted.
So now you've simplified your 1 app server into 2 app servers that aren't even the same language or environment.
Thus creating cleaner, more focused, more testable, likely faster, and more maintainable code bases. Which also adhere to the Single-Responsibility Principle. We as developers already offload certain tasks to separate servers. Do you use your app server to terminate TLS connections? You could; but why would you when Nginx can do a much better job of it? You could store you application data like usernames and password…
The only time I can justify SPA is if you’re primarily differentiating via the UX.
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…
The downside there is that you're then forced to build your application as a completely separate service and static site. With this approach, you can stick single page app where the UI needs to be more stateful and then use traditional server-templating for other things. I'm doing this w/ phoenix now and its nice because my typeahead search is done as a JS component, but the corresponding index and show pages are sti…
That is not true, you just call what you need from the JS framework and you can still use the old HAML in the other areas.
Not trying to start a flame war here, buy what is the argument for using Rails over Express or Django/Flask for a new project ? Genuinely curious to know the benefits / downsides of each option
Ruby by itself is a powerful reason to develop with Rails.
I think Vanilla Rails sprinkled with a bit of React can go a long way. Not every part of an app needs the duplicity of state, or need to look dynamic.
> sprinkled with react I can sprinkle in javascript for a normal rails app to add behavior - but i thought react required moving all rendering into it? are you able to "sprinkle" with react within otherwise normal html/css/js?