I mean a json with more than just internationalized strings. Others do it also, see f.e. Deploying a Web app in 14 days, No HTML. | Wat, blogged.
The json can be created in a wysiweg gui designer. Extjs had such a thing, which was the base for sencha architect. I don’t know if it still works with this principle. If and how they handle internationalistion I do not know.
StefanHoutzager
1
ryanswapp
I’ve been working on a project that has steadily grown over the last year and a half and I really wish I would have separated the frontend from the backend up front. The larger your application gets the harder it is to manage if you have a monolithic codebase. In addition, it is SOOOO much harder to get rid of technical debt if your app isn’t split into multiple pieces. If you go the modular route its super easy to swap out pieces of code when the winds of developer community preference change. I’d 100% recommend doing a separate frontend and backend. You definitely need to have more technical skill to write a program like that but learning whats necessary to build an app like that will pay you back big time in the long run. That said, if your app isn’t serious, you don’t plan to ever work with anyone else on it, and you don’t expect it to be very big you probably can just roll with a server rendered phoenix app.
2
andre1sk
SPA for many sites means need to run node on the backend to do server side rendering. If you can get away from the need to do an SPA you can save yourself a lot of pain.
1
StefanHoutzager
??? Seen this one: What every Node.js developer needs to know about Elixir - Bryan Hunter - Youtube?
0
andre1sk
Yep doesn’t change a fact you will have to run node to do server side rendering of an SPA. Your API can obviously be in Elixir & Phoenix but you now have to support running both BEAM and node in production monitor both patch both etc. You also would have to deal with securing much more complex environment with more than double size of attack surface.
0
OvermindDL1
I have one SPA in my big application (an inter-campus messaging system integrated into a few local services) with Elm, and no server-side rendering or node is needed at all.
1
andre1sk
Sure for any app that does not need to be indexed by search engines or when initial render time is not critical you don’t need to support server side rendering.
1
StefanHoutzager
So you have no problem to get locked into an elixir backend with your frontend. That can be a legitimate choice. I named separation of concerns because I think the responsibility of rendering the client belongs to the client. Elixir is not running in the browser. A lot can be said about this but for now I’ll just copy paste some benefits after googling (saves me typing):
"Keeping server side code separate from browser side code allows teams to:
- establish independent release cycles, which:
- allows faster development in front-end codebases (which should operate on faster release cycles)
- prevent release rollbacks for server-side code when front-end bugs are introduces
- maintain clearer distinction between codebases, which:
- decreases overall platform learning curve for new developers
- improves ability for individual codebases to be thoroughly tested
- increases independence from any single framework/architecture"
0
OvermindDL1
andre1sk
There is no right answer it’s application specific. You are just balancing sets of tradeoffs with business requirements.
0