1 karma · joined December 24, 2021
What I like about StandardJS is that I don't need yet another config file just for a linter. lintrc, babelrc, webpack.config.js, karma.config.js, etc, etc. Having one less thing for people to need to understand is a nice feature in and of itself IMO.
And I actually tended to disagree with some of the StandardJS choices before adopting it. After working with it for a few weeks, I realize it makes absolutely no difference. I just have a linter that works with no config.
Here, I saw what looked like a new project. You say I should have understood right away because Glimmer is said to power Ember's components. But the Ember team could very well have built an entirely new engine for its components. I thought Ember used to use Handlebars (didn't it?) and had just recently built a new engine (aka Glimmer) instead of adapting an existing one (React, Vue, etc). But that sounded odd, hence my question.
If you see these sorts of things all the time, there may be a reason: communication is hard and we all interpret things a bit differently (depending on our experience, our mindset, our native language, etc).
What does Glimmer do that all of the existing view libraries couldn't do ? x-tags, vue, react, preact, etc, etc, etc.
Wouldn't an abstraction layer on top of any of those libraries have avoided the need to create an entirely new project ?
What's the advantage of CloudRail vs something like Apache LibCloud ?
Thanks for your help, Steve !
It was as simple as adding Vue.js itself and one JS file for custom code. I tried using Angular but right off the bat, I had to install hundreds of dependencies via NPM.
That's what I like about Vue.js. It's simple to reason about for the kind of use case I linked above.
I thought Zapier was mostly business, and it's been running for a while now: https://zapier.com/
I've been using Docker in production for a single server website and have had very few issues. I do like how easy it is to reproduce a working environnement with a "docker build" though.
That being said, I think that just using Ansible on a server is probably an easier and more reliable solution. Ansible is battle tested and allows to have reproducible environments too.
I think Laravel has the same development model.
And it has:
- amazingly simple upgrade paths, backwards compatibility guarantee on minor and patch releases
- regular, non BC breaking, updates and new features
- corporate backing
- large ecosystem of "bundles", which are Symfony's addon system
- cli tool for scaffolding, debugging and more
- strong conventions that help keep code structure clean when you are in a team of 2+ members
The list goes on and on.
I like it ! :)
It's a bit awkward, to be frank, though. When I type "ls RE<tab>", it autocompletes to "README" even though there is another file called "REST-for-TYPO3-rest.cundd.net".
So then I type in the full filename and I get "undefined":
> cat REST-for-TYPO3-rest.cundd.net
undefined
Maybe "cat <filename>" could open the URL in a window or something. It seems like the only possible thing at the moment is "ls", "pwd" and "cat README".
With Symfony, major version changes are not there to break things or bring in tons of new stuff. Instead, it just removes BC layers for stuff that has previously been working but deprecated (with appropriate deprecation warnings).
This makes it easy to switch to a new major version: simply fix all deprecated calls and upgrade, done. At least that's what I experienced moving a project from Symfony 2.x to Symfony 3.x.
Other than that, it looks nice. What about if multiple customers write in at the same time though? Do they all speak into the Slack channel that you create? That seems like it would be confusing, having all customer discussion mixed together in one huge channel.
For instance, I just recently upgraded from Symfony 2.7 to 2.8. The upgrade path was pretty much "Remove all deprecated warnings, upgrade your Symfony package, done". The same upgrade path is used from Symfony 2.8 to 3.0, which makes it really easy to upgrade.
Symfony, as most PHP dependencies, can be installed via the "composer" package manager, which is pretty much the only package manager that is used in the PHP community, it seems. As dchesterton says, it is a very good piece of software.
Coming from Symfony (PHP), this just feels right: keep moving but make it easy to follow along.