HN user

8lall0

43 karma
Posts1
Comments64
View on HN

Imho, while i agree on the marketing side of the problem, there is one more, and probably, worst problem: at $JOB, every single PHP you're going to find has to be treated as legacy, no shiny stuff, no proper sane way to work with it, incosistent envs unless you're lucky enough to have a dockerfile and some scripting that can do the heavy lift for you.

All of this for the second lowest wage after JS devs. Not worth it.

I'm using Go and i'll never go back in the immediate future: go run . and i have all of it. Period.

PHP should strive for something like this.

Pretty odd article.

WASM is not so supported, but it's not like a major technology right now.

If you need complex UIs, separate backend and frontend and write the latter in something well supported (like, i dunno... JS)

"The days of crappy NPM packages are over" said no one ever, and no one will ever say.

TS is never going to catch up with Go performances, and the lack of IPC and true concurrency actually is very bad for backend services that need to handle stuff.

I think the OP wants to use Go for stuff that isn't supposed to do with.

Solar will never take over PER SE. It's intermittent and storage is expensive and inefficient.

I hate those articles where you put the one-solution, the energy problem must be addressed with multiple solutions.

3 months for web-dev is a very short period of time.

Web Dev takes a lot of exercise and expertise, plus CSS and JS are beasts that are completely different from more "classical" languages (like PHP).

Take your time, start from the basics (HTML, CSS and modern JS) and THEN try to use React. The world is full of React devs that don't know JS, you can be different and more proficient.

1) No, no, no, please avoid stuff that needs to be indented in 2021. YAML is more than enough to prove that is a silly thing to do.

2) If your configuration file is too big, maybe you're doing it wrong.

3) TOML is by far the less ugly format for configurations that i've ever used. Far from perfect, but it's predictable and doesn't require indentation.

I see only one reason to use custom JS UI stuff in a project: if it's an internal tool and you and your colleagues (and all your tech department) use those components when programming.

Otherwise i would use a framework, it's much reliable. If you don't want to deal with the React/Angular complexity, try Svelte, it has the best dev experience if you come from vanilla JS development.

You can export your SVGs with fill="currentColor" and your color attribute onto the SVG tag or its container would work.

Since at $JOB i'm using SVG icons with more than one color, i use fill="var(--svg-color-base)" or fill="var(--svg-color-accent)" so i can precisely set which color i want, in a perfectly scope-able manner.

The greatest advantage is that you can reference externally your svg with xlink.href on top of your website: you have to make one more request, but it's cacheable. Pick your tradeoff :)

That's because he's using React, i'm using an svg sprite sheet in a simple html page, with native <svg> tag and works like a charm. If your svg set is small, you can even inline it: you lose cache, but you save a request so you can choose your tradeoff.