Was very excited by Exilir coming from Ruby, however found 2 issues that made it hard to work with:
- Pipelines are hard to debug. You can’t just throw a debugger just before the line with the issue.
- Phoenix is very bad at serving static files. It was a nightmare to import a new CSS template requiring to convert everything to work with bower first, or dump the files in the /priv directory to make it work.
> Pipelines are hard to debug. You can’t just throw a debugger just before the line with the issue.
You absolutely can. Just change,
```elixir
users
|> send_email_with_money()
|> do_complex_thing_that_crashes()
```
into
```elixir
users = users
|> send_email_with_money()
require IEx; IEx.pry()
```
I turned the `require IEx; IEx.pry()` into a snippet just to make life as easy as it is in Ruby land.
> - Phoenix is very bad at serving static files. It was a nightmare to import a new CSS template requiring to convert everything to work with bower first, or dump the files in the /priv directory to make it work.
Well, two sides to this. For one, Phoenix uses Webpack now(since finally the war to see what app bundler would win is over).
But even when you did use bower- you should've been able to just delete `phoenix.css`, copy your template in, and in `app.css` put `import "template_name_here"`.
Yeah, but you do need to edit your actual pipelined code to add a debugger. That's annoying.
> Well, two sides to this. For one, Phoenix uses Webpack now(since finally the war to see what app bundler would win is over).
We shouldn't force devs on Bower or Webpack. If I want to try out a new theme just bought on ThemeForest, it shouldn't take hours to make it compatible. Or to force to do the /priv/ hack that seems unelegant.
> We shouldn't force devs on Bower or Webpack. If I want to try out a new theme just bought on ThemeForest, it shouldn't take hours to make it compatible. Or to force to do the /priv/ hack that seems unelegant.
You could at any time have installed Phoenix without those. And what's so hackey about /priv/? That's where you can dump things that you know will be served. It's literally the intended purpose of the folder.
Both of these points are False, point 2 I’ve been integrating a bootstrap framework and sass and it’s super simple; I put the files in assets, add npm install —save sass and that’s it!
Then debugging a pipeline is as simple as dropping in IO.inspect between statements as it returns the content as well as printing.
I agree about the inspect / pry not being a real debugger but could you expand on your problems with the debugger and pipelines?
Are you using the Erlang :debugger module?
The only "problem" I see is that we can't set a breakpoint on the first line of a Elixir pipeline, but to see the value of variable from that line we can set a breakpoint on the last line of the pipeline. To see why that happens we can try stepping through a pipeline with the debugger: First "executed" is the last line of the pipeline, then the second line, then third etc and it looks like for the debugger the first line of the pipeline never happened. I don't think this is a big problem to be honest.
I agree but this type of comment also shows your lack of experience. Very rarely do you personally get to make a choice about the technology used. In this case I’ve come onto a project to fix a load of bugs and restyle something that already existed. I’m not going to come in and redo everything from scratch before delivering something...
- Pipelines are hard to debug. You can’t just throw a debugger just before the line with the issue.
- Phoenix is very bad at serving static files. It was a nightmare to import a new CSS template requiring to convert everything to work with bower first, or dump the files in the /priv directory to make it work.