Is the new implementation still Rails?
504 karma · joined December 28, 2011
For anyone interested and building sites with Next.js, I've released a plugin for optimizing images and converting to webp with fallback to jpg/png: https://github.com/humaans/next-img/
It's interesting.. I'd guess VC money is not in line with what the scuttlebutt community would think is the right approach for creating a better alternative to current giants. But at the same time it's clear that you need a lot of time and money to create something polished and mainstream. There must be multiple ways to achieve the same goal.
We're focusing on making it beautiful, as straightforward and as efficient as possible, really fast, remote and distributed team friendly and useful in all sorts of small ways. For example, you can see the local time of your remote colleagues in the directory or their profile. Hovering over your time off balance shows you the breakdown of how it's calculated - days accrued, booked upcoming days, booked past days, carry over - so you know exactly what's going on. The "filter by anything" search lets you find an individual or people from some team or city quickly, and so on.
It's built using Node.js/Postgres and React.js as the key tech. The API and UI are fully realtime since the backend is powered by Feathers.js (https://feathersjs.com/).
Feel free to try it out – it takes only 2 minutes to sign up. Feedback is welcome. Also interested in what you'd like to see in a tool like this. The HR space is quite broad with a lot of interesting tools popping up and we're still exploring the ways we could have the most impact to help businesses be more efficient.
- babel compiles async/await down to regenerator when using modules: true (at least for now) - the definition of “modern” browsers will change eventually and module/nomodule detection will not be relevant
Which is why I’d use ua sniffing: https://github.com/KidkArolis/jetpack/blob/master/docs/07-di...
Countly - a little richer, e.g. geo view
Matomo - the most feature rich, closest to GA (haven't used)
Specifically, I would think 99% if stuff being shipped today is bundled with tools like webpack.
- meant to be not React only
- less opinionated in that it doesn't include jest
- smaller in scope/code, so easier to understand what it does by reading the code (?)
- allows extending configuration
- focus on SPA use case with jetpack/serve or proxy features
I should probably give CRA a proper spin though, it's popular and V2 seems pretty good.
The challenge of course is the diversity of the ecosystem. Different projects are trying to address it differently, e.g.
* CRA is opinionated and unconfigurable
* Neutrino/pwa-cli propose a higher level plugin approach (i.e. install a plugin, without needing to configure it, in webpack plugins take many lines of configuration to configure)
* Next/Gatsby use a plugin system as well but are also specialised tools which means a lot of decisions can be abstracted
* jetpack tries to be application/use case/framework agnostic and provide you with the most commonly used/useful foundation, you can optionally add extra (e.g. sass), but you don't have to recreate the foundation (i.e. es6, jsx, modern css, css modules, hot reloading, serving, producing html, etc)
It's also about the DX, jetpack lets you run a dev server with a single command, it lets you analyse the bundle with a sigle command, it builds an optimised, split chunk bundle with a single command.
Just pointing out some motivations behind the project, I'm a fan of webpack, been using it for many years.
[1] https://github.com/KidkArolis/jetpack/blob/master/docs/08-co...
I'd argue one of the reasons Next.js is so popular is because you can get started with no configuration. It has optional configuration, but all the webpack config, css, hot reloading, route splitting, etc. all serves as a solid foundation.
I wanted something that is a good fouondation for _any_ project. If it needs extending, sure. But there's not much to remove.
You could argue you don't need all those plugins, but.. I would like to use jsx, async/await, css autoprefixing, css imports, hot reloading, compile it all for older browsers, split chunks and generate html. Those seem to be expected features today (or maybe that's a wrong assumption I have)?
Requiring the users to install 20 or more dependencies (@babel/, @postcss/, webpack-*, etc.) and write dozens of lines of configuration every time just doesn't feel right (or maybe it is..).
And we know what the developers need, they need to bundle a web project in a way that's optimised for production, js and css compiled to run on N (configurable) most recent browsers (optionally). But that's not that trivial in webpack, if it was, perhaps we wouldn't have so many abstractions trying to improve upon status quo.
Perhaps that's just an inherently difficult problem. E.g. there are many many ways to handle CSS, people use variety of transpilations such as TypeScript or Flow, projects have different requirements.
Another data point is that Parcel this problem in a much more "everything works automatically" way and it's really resonating with people.
* nodemon
* npm-check
* ndb
* serve
* webtorrent-cli
* jetpack
E.g. you could do something like:
cd ~/Desktop/foo
npm i somepkg
echo console.log(require('somepkg')()) > index.js
jetpack