9 ms·
There’s a deep understanding of the tools they use every day. They may use a framework as a starting point, but they also understand the JavaScript that makes t
by austincheney 5y ago
There’s a deep understanding of the tools they use every day. They may use a framework as a starting point, but they also understand the JavaScript that makes the underlying work. They leverage CSS like a fluent language, manipulating DOM elements to their will. They see browser APIs as the foundation of their process rather than puzzling concepts pulled from Stackoverflow answers.
I wish that were true, I have not seen this in the corporate world and it appears absent in the job opening details of startups.
My experience tells me this:
* If you are really good you can be up and running a new project in something like React in 2 or 3 days.
* If you are really good you can be up and running without any framework at all in about 2 weeks.
* If you don’t use a framework you are forced to make tough design decisions early. This is critically beneficial and pays interest over time. Those decisions allow you to scale in ways frameworks cannot.
* The value of frameworks is over estimated for the wrong reasons and under appreciated for reasons developers don’t immediately see.
* Working directly to the DOM (even without query selectors) is amazingly easy, but it takes practice (just like writing CSS). The value is not the data, but the relationship between the nodes. That line of thinking reminds me of this board game called Othello.
* State management is less easy but still not challenging. https://github.com/prettydiff/wisdom/blob/master/state_management.md https://github.com/prettydiff/wisdom/blob/master/state_manag...
- nbardy 5y agoThis is pretty drab. I can be up and started in about two minutes with React, typescript and parcel.
- leephillips 5y agoHe didn’t say “started”, but up and running. I interpret that as having a basic working site.
- echelon 5y agoBy the time you build your solution in native DOM, you've missed the market. This is why we don't write applications in assembler. If performance is your only metric, write Rust and target WASM. But that's probably not the right solution for 95% of cases.
- krychu 5y agoVS Code must have been lucky then.
- echelon 5y agoVS Code requires more careful engineering than a CRUD web app. It also has a lot more dedicated talent with eyes on the problem.
- austincheney 5y agoThese technologies aren’t limited to CRUD apps.
- austincheney 5y agoI built a Windows like GUI, including basic file system display and population, using native DOM for the front end of a node app. It took me, one person, two weeks. It includes state management. If you think that’s the same as writing assembly you probably aren’t the right guy to drive the success of a startup.
- echelon 5y ago> you probably aren’t the right guy to drive the success of a startup. Since when did giving honest opinions about speed and practicality merit personal insults?
- austincheney 5y agoIt’s not an insult. If you took that as an insult you probably aren’t as open to honesty as you imagine.
- echelon 5y agoI'm probably not a lot of the things you call me. :)
- namanyayg 5y agoWhat kind of design decisions are you talking about, any examples? What would you suggest for interactivity and JS; e.g. in a dashboard application with crud records/posts?
- austincheney 5y agoThe benefit of a dashboard is real time status updates. My recommendation is don’t think about the JS at all. None. Instead focus on services. Get the content you need. I recommend web sockets so that the updates come to the browser asynchronously without polling the server. Once you have what you need you will figure out the most ideal user interactions.
- mason55 5y agoYeah one major benefit of a framework is the ability for new-to-the-team devs to get up to speed quickly and in general for people to understand what’s going on without having to pickup your domain specific stuff. Similar to reasons Java became so popular in the enterprise
- nawgz 5y agoI’m not sure I agree with your takes on frameworks. It definitely depends on what you’re building, but in React to have composition and reuse for free immediately sets it apart from any bespoke solutions. I’m also struggling to imagine how you propose to out-scale the React framework with early & tough design decisions... these are Facebook engineers that made those same decisions, and they managed to scale the framework to Facebook levels. You understand that they may be the UI leaders of the world, yes?
- jiofih 5y agoFacebook, the product, did not use React until very very recently. Do you use FB? If Facebook’s interface represents the “UI leaders of the world” we’re in troubled waters!
- nawgz 5y agoCan you say more about why we'd be in troubled waters for such a thing? Facebook and its non-titular products are probably used by the most people in the world. The org is 50k people, and I imagine their engineering staff is proportionally quite large - they rarely introduce bugs and seem to have quite a good update cycle. There is a huge featureset and the website performs very well.
- jazzyjackson 5y ago> the website performs very well IME you could measure page transitions in seconds, it is an extremely slow website
- austincheney 5y agoIf composition is your first concern you lack vision. Instead start from a good idea, form a vision on how you want to execute that idea, determine what you need, and then build those pieces in isolation. You get separation of concerns for free and composition becomes the last step. If you spend all your energy over concerns on how to build something you are spending creative energy thinking about what cool things to build.
- brotzky 5y agoHey, OP here! I think I could've worded that better. It does sound a bit anti-framework when it wasn't meant to be at all. I was thinking more in broader terms where you'll inevitably be using Browser APIs even within a framework like React. I specifically tried to avoid talking too much about stuff like React, Next, Tailwind, etc.