I imagine unpopular opinion, but I don't like the React design or syntax, its adoption was one of the reasons it made me move away from front-end. I'd rather Valdi and other efforts have a different opinionated design and syntax, less over-engineering and more fun.
There have been solid efforts with niche adoption that have quite nice UX like Umbrel [1] that allows installing all the mentioned and a ton more open-source apps [2] just by using a UI. It was spawned as bitcoin node hardware+software combo but expanded and is now primarily about self-hosting.
The rise of better home internet connections worldwide will make this even more attainable for more people. At least on my low-level EU country that has been always lagging to progress tech-wise, we've seen great progress on fiber internet adoption, so I have hope of acceleration.
There are many solutions like Umbrel, but they all suffer from limited amount of apps, and depending on someone maintaining them. You basically have to choose them by which apps you want to use, and how that it will get maintained long enough.
What we need is something more universal, like a more userfriendly docker, or something like flatpak+hub for server-apps.
Clickbait title aside. I find that ethical issues around AI raised by Musk etc. shouldn't be around AI taking over the planet, but rather have ethics around overfitted models or otherwise unrealistic models being pushed for PR or whatever and responsibly playing with people's health and hopes.
Quite arguable numbers that seem to be used to drive traffic to this site rather than do a proper scientific report like done by the University of Cambridge https://cbeci.org/
The CO2 emissions heavily depend on the actual use of renewable which nobody can be sure about. In some cases like bitcoin mining using fuel that would otherwise cause CO2 emissions, you actual have a net gain. (See companies like https://www.upstreamdata.ca/)
So even by those arguable arguable CO2 emissions it's actually less than 0.1% of the world's total.
I wish people that have knee-jerk reactions about this, actual think about the big picture and what actually causes high CO2 emissions and offer way fewer benefits than censorship-resistant money.
The luxury fashion industry for example for a long time has had a big negative effect, from drying up whole lakes, to child labor to effectively destroying villages for what... anyhow.
Security is multi dimensional matter, you can't just rely on rules like "no ssh to root" or "password should be more than 20 characters".
In my case ssh is allowed from 2 IP addresses (much more useful rule then "no ssh to root "btw!) with key auth (passwd auth disabled). Don't see any problem with that.
Various banking (sub)systems break all the time. We just never get any postmortems or public apologies.
This reminds me the saying "Never admit a wrongdoing and you'll never be wrong".
It's great that we get several of those new startup banks (Monzo, N26 etc.) that provide superior experience and slowly show what horrible things traditional banks were getting away with.
Some months ago I transferred some money between two accounts at different banks. The money arrived _twice_ in two different accounts of mine at the destination bank. I contacted them and asked them to cancel the second transfer, but they just told me it would get automatically denied for insufficient funds at the origin. They also warned me that if it happened again my account might have restrictions placed on it.
An apology would have been nice, but I suppose unwarranted threats are more in character.
That's just "decentralization" by obscurity. (emphasis on the quotes)
That aside, the main problem isn't centralization but rather the trust level. The point is to not have to trust someone isn't serving you the false data. Contracts must be created and ran only when the data can be cryptographically verified to be true.
There are no trustless oracles if any of the required data are outside of the settlement system (e.x. blockchain). Even when the data are inside, you still have cases of collusion that make things problematic.
People are trying to sell something that's close to impossible. Especially when they try to add infinite flexibility on it.
Even with the currently low stakes there have been incidents of "oracles" getting compromised. There are several strategies to try and camouflage a centralized oracle to a faux decentralized entity but eventually if stakes get high enough, your entity will become a target and it'll become once again obvious what's happening.
Yes. Go to http://www.leonardodigitale.com/index.php?lang=ENG. Flash must be enabled. Click on "Browse", choose "Codex Atlanticus" (not the Hoepli edition). Then for every page you read, it displays the text (in Italian) from that page in the other "window".
I'm quite surprised by the number of comments on Sass/CSS pre-processors being of little to no value while we have created a huge complicated Frankenstein mess with webpack/React and the rest.
Well some of us think webpack/react and the rest are even worse and that a page-reload never killed anyone.
I don’t work in a tech-focused business, because I work in the public sector. That means our funding is fairly limited, even though 90% of our workforce spends 5-8 hours a day on some for of smart device or pc. Because we’re limited, however, we need to be careful about how we spend our resources, and that means we simply can’t keep up with the modern frontend environment.
If all you do is angular, then the transition from AngularJS to angular 2 might have been smooth, but it sure wasn’t for us, and neither would the big react-versions be.
We also can’t really take advantage of the package/library environment because we’re not as fault tolerant as others. We can’t have security issues, but we also can’t code-review 70 packages/libraries every week because there was an update.
As a result we’re back to using the old MVC frameworks that don’t change every day and have solid standard libraries. We did buy a frontend “platform” so we can have things like editable grids without constant page-reloads, but in general, JS is something we add to a specific component only if it’s absolutely necessary.
I am looking forward to when Flutter finally has the ability to build websites. Because then we’ll have both mobile platforms, web and desktop frontends covered in one tool. Which is frankly exactly what we need to be productive in 2019, that or we’d need to hire 2-3 people, and the latter is just not happening.
As a front-end developer it sounds just like the perfect job for me. I'm so tired of fighting the infrastructure and tooling instead of doing real work that I wish I could go back in time to work in simple MVC project. I don't really care if it's Rails, Django, PHP, .NET or Java. On my previous 4 jobs I wrote SPAs for products that weren't supposed to be a SPA. I wonder if there are still interesting products being built with these 'old' tech. Where I live certainly there isn't.
Not like C/C++ programs, where we have a super simple setup of Make, config, and autoconf. Like checkout this easy-peasy Make file: https://github.com/apache/httpd/blob/trunk/Makefile.in . Even a child could understand it.
I guess my snarky point is that build systems are complicated. It's like the Bjarne Stroustrup about programming languages. There are two kinds of build systems: the ones people complain about the ones no body uses. Robust build systems have to handle the nearly endless combinations of different requirements each app brings to the table...complexity is table stakes.
Modern web apps are built to be able to run on a myriad of different platforms, as they have to maintain compatibility between tons of version of several different browsers running on a slew of different device types running different operating systems. Did we think that was going to be easy?
People like to shit on webpack, but I don't get it. It's a well thought out tool that works extremely well.
And what are the alternatives? Yes, yes, yes, I know, your blog/website/thing you have is just plain ol' html and and you stick some javascript in a script tag or whatever. No need for any of these fancy build scripts, blah, blah. So what? That's like telling the people at lucene that all this arcane index stuff is overkill because you just search your hard drive using ripgrep.
You can't make a real app like Slack, Spotify, VS Code, or Google Docs without a serious build process. People are making photoshop, for the browser. They're not going to do it with ES3 they write directly into a script tag.
> People like to shit on webpack, but I don't get it. It's a well thought out tool that works extremely well.
The problem isn't that webpack is bad but too many projects use it where there's not need for it. Also for newcomers to the js world it looks terrifyingly complicated. Sure those bootcamp rookies eventually discover how terrible C++ buils are but who cares since this is more like comparing a spoon with a shovel.
> The problem isn't that webpack is bad but too many projects use it where there's not need for it.
Well, I feel that bit of nuance gets lost most of the time. It’s usually just simplified to “all these JS tools are a mess.”
It’s like if people all started complaining that rust is bad because they saw someone write a rust program when that person should have just written a bash script.
I am quite surprised at how the wheels have turned. I remember a year ago I was interviewing people and each single candidate listed SASS as a skill, and almost everyone during the interview claimed its their preferred method of working. (my team so far has been using plain css and are happy with it, so that surprised me a lot back then).
Is it considered bad practice now? How did it rise so quickly, how did it fall so quickly, what's going on in the web dev world?
Sass and other CSS generators were useful a few years ago for rapid code generation. However, CSS has caught up as have editors and it's hard to see what real advantage Sass has today.
Some novel things like a primaryColor variable to easily adust your theme is easily replicated with a traditional find/replace.
The fewer frameworks / compiles-to X languages you have to learn the better.
IMO, a little redundancy is better than a little complexity or a little dependency.
Using a find and replace instead of a variable holder is extremely bad practice. I should not have to copy/paste my site’s brand colors every time.
The original reason I switched was for nested structures so I could stop repeating myself. E.g.
div {
&:hover {}
.class ul {}
}
This made it much more pleasant to write in sass.
The other thing is mixins. If vanilla css doesn’t support this then it’s still a no-go.
Lastly I’m confused why sass of all things is an issue. It’s basically css, and very lightweight. You just add one step in your preferred build tool to transpile sass -> css. “vanilla is magically better” is not an argument.
I used to write only in Sass for these same reasons, but switched back to CSS.
CSS now has variables (if you really need them -- chances are you don't).
The redundancy of writing a selector multiple times is sightly annoying, but I don't think it rises to the level of value I need to include a new dependency in my app or build pipeline.
These are preferable because you can compose them as needed for elements, instead of having to make extra classes.
> CSS now has variables (if you really need them -- chances are you don't).
I fail to see how you could -not- need variables. Not many, mind you, but using none at all boggles the mind. For starters, DRY code is fairly fundamental. When you update a referenced variable you only need to do it in 1 place. Relying on "find and replace" leads to "oops I accidentally missed one, now we have a bug that could have been totally avoided".
It also helps with consistency for site theming/branding. You can define $primaryColor, $primaryHighlight, $secondaryColor, $textColor, $backgroundColor, etc, and reference these down the line instead of copy/pasting and getting bugs if the specs change.
> When you update a referenced variable you only need to do it in 1 place. Relying on "find and replace" leads to "oops I accidentally missed one, now we have a bug that could have been totally avoided".
Isn't that the point of selecting classes in the first place? That said, I understand the utility in using it for things like individual colors, as you described.
Classes do suffice if you follow the convention of "small, atom-like css classes". I personally hate this style and prefer compositional css classes for a component or a structured object.
Sass is very much still useful today. Mixins, used sparsely, can be very powerful and avoid large doses of redundancy. Also variables with good names make the job a lot easier than communicating around hexvalues.
Variables alone are not a reason to use Sass anymore. There are CSS Custom Properties [1] now, which are even more powerful in that you can dynamically override them in specific sub-sections of the DOM. The only downside is that Internet Explorer 11 doesn't support them (if that's important for your target audience).
