Something I see happen time and time again in frontend development is developers reaching for conveniences. It may be the hot new tool in town, it ...
For further actions, you may consider blocking this person and/or reporting abuse
While I agree with the sentiment of "don't just use stuff without considering cost vs. benefit", I am not sold on "does the browser natively support it" as the key metric. The browser API is notorious for its weirdness and good intentions that are executed poorly (e.g. web components, drag and drop, modals, indexedDB ...) and I wouldn't treat it as some kind of gold standard :)
Uh, web components are not executed poorly - they are low level, but that's good. And you can use libraries that run in browsers with no special tool chain or fork of standard languages require that make writing web components very nice.
You think "runs in the browser" is not a good metric for code thats meant for the browser?
Whether something runs in the browser or not without transpilation/compilation is not a very good metric, no. For example Svelte vs. vanilla JS
This is exactly the point though, when you use Svelte, you lock yourself in to Svelte and Svelte's toolchain. Svelte does not run in a browser natively. Again, that's not to say that Svelte is bad (it's very clearly not), just less portable than vanilla js. The same goes for other compilers, like Elm for example.
I do think its fair to say this operates on a bit of a different level, though, there's a very clear difference between building an app with Svelte, and publishing a package to NPM.
Right. At the end it all boils down to cost benefit analysis
I've seen frontend job applicants being able to use destructuring in parameter handling, but unable to differentiate between a function reference and a function call, as an argument for setTimeout.
Clearly they must be performing at a certain level, in their current role, but lacking the fundamentals. Relying on conveniences can have a huge cost on one's development and career as well.
Great read!
By the same token, I have interviewed candidates who have been through a React bootcamp and spent 3years on a React project but did not know what the
thiskeyword did in JS or even what the CSS box model is.This might be a controversial position but I fear when it comes to frontend developers we might have set the entry level too low.
When ES6 came along we all jumped on board and started transpiling it because not all browsers supported it yet. But it seems like the transpiler became an unshakeable addiction. There's always that experimental feature that is too sexy not to use. And then there was TypeScript. Of course we have to use TypeScript!
Thanks for saying this. It needed to be said.
Angular v16 has this esbuild support which makes the build process faster. But for now it doesn't support the Tailwind. But does support SCSS and css, natively.
If I have never relied on one tool for convenience (tailwind) I would have wanted other tool (esbuild) to play nicely together.
Why shouldn't tool use conveniences by default? Many of them lower the entry barrier for people to get into development. Especially tool for non-devs.
Read the post :)
I've read it. Have i missed something or missunderstood something?
You stated absolutly avoid conviences by default. My take on it is, "It depends on the tool" and "They help to reduce the entry barrier", so for me it's not a must to avoid them. (Thou I have to admit I interpreted convieniences a bit broader than just for JS, but also for tools like IDEs)
Okay you read it, I will believe you, but did you miss the part where this infinite and growing loop of imposing conveniences was mentioned? I believe that's your answer.