lol I missed this one!!
Nope, luckily for everyone I’m not a PM 😆

since hooks has been a thing, i honestly struggle to see any value provided to us by redux other than extra dependency to maintain and extra boilerplate

creating a pub/sub-ish state manager is a child play, it goes well with typescript, memoized selectors are simple to test and implement... what else do i need?

Aaaahh you peasant... anything else than dark theme should be persecuted 🤣

relax, it could have been PHP

@Wisecrack you mentioned a bunch of stuff in the first post... give them a try and then figure out how contextualise them with the big techs that we cannot avoid these days (like angular, functional flavours of react, various server side rendering wrappers etc.)

for example you deliver an isomorphic react app, let's say Next.JS for SaaS product in a serverless env.
if you use grunt because you like it, fine, it's not the end of the world (still it's an extra dep)
but if you use grunt because you **need it**, well... i already know enough about your project to call it garbage.

that's what i meant a few posts up.
finally we're having emerging conventions. follow them, and everything stays dry and simple

@Wisecrack i understand your point

basically, I don't care if new devs know or not all the tools: i'm looking for a mindset

i want someone with real JS literacy (even if we code only in TS), someone who takes no shortcuts, and is able to follow rigorous TDD (and here thinking functional helps a lot). i don't want to see any jquery-like code.
you know react hooks but not rxJS? you used only grunt when instead we use npm scripts? i couldn't care less. but you need to be able to separate 🍫 from 💩, bearing in mind that we're using a LISP-like language and our delivery scenario is event-driven.

a developer that shows real understanding of these aspects is a real frontend developer to me
but they're rare and typically, legitimately very picky as most of the times companies don't consider client-side programming a first-class citizen in their stack

sass was a great solution, then it became a good compromise... but guys, now 2010 is long gone.
for new projects sass is acceptable if you deploy on premise. if you go cloud these days you want to limit XHR and keep side/lazy loading for additional business logic, not stylesheets

single JS bundle and goodbye argentina

@Wisecrack, 90% of what you mentioned it's either garbage or old tools that anyone with common sense already removed from his stack.
slowly, but frontend world is finally evolving into something more stable and structured

the problem is that frontend-land is full of ex java-ers (or equivalent) who love to over-engineer and over-configure everything and instead ignore conventions, and even worse, full of wannabes who just watched frontend101 on youtube and consider themself pros.

...and i didn't mention web designers, from whom arise another huge part of this big misunderstanding

well, i never used redux in prod, and i’m pretty sure i never will. good design, principles and robustness, but poor S/N ratio.

i wrote many pub/sub-ish stuff, some state managers, but redux not really. always went for observables/subjects before, now with hooks and proper typing system i’m dropping rxjs too as it doesn’t give me anymore the extra boost it used to

general literacy in CS and basic maths (algebra especially) is ok to grasp the underlying concepts.

to be a master tho... well, nobody lives so long

you're all talking about the outermost layer of frontend, rendering stuff, markup, css , etc...

you bring frameworks around in order to have code reuse across projects, testability and to move part of the logics on the client (which cpu power comes for free, from a BE perspective)

a crappy website is a crappy website, independently ofJS.
the role of JS is mostly to wire and instrument XHR calls to logics and, by reacting to their responses, produce decent HTML/CSS
you don't use frameworks to make "websites", portolios etc. if you do, you got no idea of what you're doing and what frameworks are for.

it's not 5K lines of decent JS that make a client struggle.
but shitty code does, as usual (good code in wrong place is still shitty code, btw)

imho the typical use case is roles/auth/capability based stuff as you said
at the end of the day you still have to produce plain html in a way or another

<almost-offtopic>
anyway, it's 2019, I find insane to keep using those kind of tools to render whatever server side

i mean, server side rendering is ok, sometimes is good, sometimes is needed, fair enough.
but the idea of a view engine / templating system so coupled with the backend logics, to me is totally crazy as a concept per se

i prefer having a complete stateless backend that emits only data, and a server side rendering layer that emits html and deals with frontend states and events
</almost-offtopic>

jumping from classic OOP/C#/Java-land to Nodejs, and maybe some React too on the FE, is a huge thing, not everyone likes it

i love having code over conf, no xml here and there to configure everything, properties, dotenvs, or big inheritance trees (actually, i consider prototypal inheritance quite better "by-design").
but that's not important, that's only my opinion.

debugging in Node.js these days isn't any worse than Java/C#, but it's very true that when .NET (here's it's way better than java) just works out of the box, the debugging environment in Node needs paradoxically a not immediate tuning, especially if you go with typescript

the most important feature of Node.js world, to me and by a ridiculously huge margin, is how short the feedback loop is compared to compiled langs. running thousands of unit and integration tests in a matter of seconds every time i ctrl+s something is priceless to me

it took me 10 mins to see that 😂
time for a coffee

@sunfishcc blue is banned in your office, i have a tenkeyless one with monsterclicky greens at work 😂 and a lot of people with blues anyway

headphones, music and gg

Varmilo VA22M
definitely not a cheap brand, but quality is outstanding

i don't know if they have it on the website, when I need something from them I normally write an email

Just because they don't have the nerve to admit their frustration seeing semi-illiterate web designers doing awesome stuff with very basic unsophisticated tools 😂

i guess mr nadella is already torpedoing another internal team

assertTrue(true);

all uppercase, well... yeah, i guess

Linux properly written is fine 😉

there's a good article supporting var rather than let
https://davidwalsh.name/for-and-aga...
i couldn't disagree more tho 😉

we already have function scoped stuff: parameters FGS!!!

otherwise we'll never get rid of the freaking closure problem. how beautiful, isn't it? stupid var...
http://jsfiddle.net/thatsnotnice/...

it is actually a good thing
so you can better smell bullshit from miles away instead of wasting time diggin into the tutorial 😂

It's not only about IE, a lot of browsers added support gradually. For full support of grid we're about 85% worldwide now. A missing 15% is still worth the effort IMHO, and the good thing about frameworks is that they come with premade fillers

what i normally do is go with grid in order to reduce a 2-dimension page to a bunch of contexts i can then easily handle and refine with flex

IMHO they come together, there's no "this XOR that"

i don't know much about blueprint, but if you take the grid road, don't forget a fallback css for IE and older versions of chrome/FF

i use typescript in every project, both frontend and backend

2 main reasons for me
- static typing makes intellisense waaaaay smarter in editors (this is actually the main reason)
- interfaces come very handy sometims

beware of static typing tho, it doesn't make your code any better. don't do the mistake to "trust" your code more than you should.
you need testing for that, not types. unit, integration and e2e.
and the feedback loop with TS is LONGER than vanilla JS, not shorter (but imho it's still short enough)

in academic tdd doesn't exists lady time I checked 😂

In my team I enforce it quite rigorously

how's the feedback loop with wasm? like... can i have 5K tests run in seconds every time i press ctrl+s? otherwise it is just hot air

i know nothing about wasm, but from the dev perspective i just wonder how a truly compiled thing can match the productivity of JIT-compiled stuff (maybe it does and i just don't know it)
i'm talking of writing code here, i don't question the quality of the final artifact

tdd black magic

in general, i favour declarative languages, markups & co.

i'm no expert of GUI development in desktop environments, but as for web dev markups are quite a good tool
and as for web, unless you develop for intranet or you use a good server-side rendering system, normally you want standard-compliant HTML on top of everything

i use deepin atm... it does the job

never tried i3, is it any good? normally i'm not a big fan of tiling wms