61–70 of 101 posts
Earlier quoted context omitted.
This is why Phoenix is ditching webpack! The story on the Elixir side is more compelling. I'm glad the team made this decision. https://sergiotapia.com/phoenix-160-liveview-esbuild-tailwin... Also medium sucks, please don't use it to write developer blogs. People can't read your article!
Thank you very much for the blog post, it will save a lot of time and hair.
Earlier quoted context omitted.
3 months might be (close to) hyperbole, but webpack/JS package management is a source of consistent pain. It sticks out like a sore thumb across my web stacks (PHP/WP, Ruby, Elixir) and its brittle complexity causes the most unpleasant dev experience I have to deal with. I doubt it's my incompetence alone - npm is involved in over 25% of Phoenix's issues!
I maintain a Rails codebase and a Node codebase. We are using esbuild for Node / JS bundling, along with TypeScript. The Node project is much less of a headache than the Rails one, mostly due to TypeScript. We’ve also made an effort to minimize our dependencies. We have fewer npm modules than gems. All that to say, Rails is fine. But Node is also fine, if you treat it more like Go (minimal dependencies, lean on the v…
Another reason to move to Elixir from Ruby...
Elixir isn't even in Tiobe's top 50 https://www.tiobe.com/tiobe-index/
It's telling that most instructions deal with the Javascript toolchain and not Rails itself. And let's hope that everything works and none of the 2000 imported node_modules blow up when this tutorial is 3 months old. I'm looking forward to Phoenix 1.6 which ditches Webpack for esbuild. Every step away from the insane churn of the modern frontend world is welcome.
> And let's hope that everything works and none of the 2000 imported node_modules blow up when this tutorial is 3 months old. We have recurring Jira tickets for updating npm dependencies every two weeks. One developer is occupied between half a day and two days because the amount of breakage in the npm ecosystem is enormous. It’s ridiculous and sucks the life out of us.
Earlier quoted context omitted.
Elixir isn't even in Tiobe's top 50 https://www.tiobe.com/tiobe-index/
Whilst I agree with you that Elixir is an also-ran Tiobe is the worst yardstick by which to measure a programming language. I can never understand why anyone takes it seriously.
I think Elixir fans should learn a lesson in being humble...
Besides Rails / Webpacker 6 and Tailwind with the JIT compiler it also includes Sidekiq, Action Cable and Turbo along with Postgres and Redis.
I'm not married to the idea of Webpacker, but currently it's the most painless way to create bundles and process your CSS and JS even if you mostly use server side templates with sprinkles of JS. I'll switch the example app to what Rails defaults to in the future but right now we're in a limbo state where combining a bunch of other independent watchers (esbuild + Tailwind's watcher) and ESM isn't a better development experience IMO.
With Webpacker and Tailwind's JIT, CSS + JS changes take 100ms and you can further optimize startup times with using Webpack's disk cache. With the above Docker set up it's configured with multi-stage builds so your final Rails app only has the end result of running an assets precompile which only runs with RAILS_ENV=production. The Webpack watcher only runs in development too.
If anyone works with Phoenix instead, a similar example app is here https://github.com/nickjj/docker-phoenix-example. There's also example apps for Flask, Django, Node and Play too if you replace the name of the repo. All of them go over the motions of setting up a base line app with Tailwind and Webpack plus whatever else is idiomatic in that stack.
Plot twist: For the Flask, Django, Phoenix, Node and Play examples I've used nearly the same Webpack config for 2 years and I continuously keep Webpack and all of the JS dependencies up to date. There hasn't been any issues at all. I wouldn't consider myself an advanced front-end developer either. I glanced their docs, found something that works and stuck with it.
Wait. So… you practically need to develop an app to start developing an app? When someone tells me to ‘invoke these 3 magic incantations’, I can sort of keep track of it. But here it seems like the instructions are to invoke these 300 magic incantations.
Earlier quoted context omitted.
> And let's hope that everything works and none of the 2000 imported node_modules blow up when this tutorial is 3 months old. We have recurring Jira tickets for updating npm dependencies every two weeks. One developer is occupied between half a day and two days because the amount of breakage in the npm ecosystem is enormous. It’s ridiculous and sucks the life out of us.
I'm sure you have a lived experience that guides what you said, but this just hasnt been my experience. We just use dependabot to issue PRs for updating dependencies, and we merge automatically when tests pass. It's never caused an issue.
It works great but the underlying problem still remains I guess
Earlier quoted context omitted.
Why not just use fixed versions and upgrade when you have a reason to?
That sounds like a nightmare waiting to happen. You have a package which hasn't been upgraded by your team for two years and suddenly someone finds a vulnerability in every version before 3.xyz.something. When you check, your version package is 1.3.5. Now you have to upgrade multiple major versions, and in all likelihood the package had transitive dependencies which have had many updates themselves as well. After sev…
Like, do you really need to import half of lodash or ramda just so you can one-line a few calls?