151–160 of 309 posts
Of 20+ applicants I've interviewed this year, only 2 knew about element.dataset and how to create a basic state scoped to that vanilla JS "component".
The issue is groupthink and using the hammer on everything.
Earlier quoted context omitted.
> The starting point for doing anything with React is where you call it to render a certain component at a certain point in your document You're trying to use the literal meaning of "you call it" to make an argument but that argument doesn't support the position you think it does. Yes, React has `ReactDOM.render()`, but did you know Angular.js also has an entry point called `angular.bootstrap()`? Vue has `new Vue()`…
I would say the traditional distinction between a library and a framework, to the extent that the industry has any settled definition for these terms at all, is about who dictates the application architecture and the control flow. A framework typically establishes a runtime environment and then calls into your code to respond to specific events. Common examples are GUI applications that run an event loop responding t…
Earlier quoted context omitted.
It's absolutely possible, dare I say easy, to do old school SSR wrong. You start with an honest to god html file. Your IDE lints it. You are happy, life is easy. Then you need a second page. So you copy some things over. Then you need a third page, and it becomes apparent that you need a way to share parts of your html pages across multiple files, in a generic way. And kids, that's the story of how I met your templat…
> And kids, that's the story of how I met your templating system. > ALL of them suck. ALL of them are incredibly hard to lint, test, get right. They scale badly. They're all awful. That's not really true. But fairly incredibly, it seems relatively little attention has been given to the design of HTML templating languages (certainly there are a lot of them, but most seem to have accreted rather than been designed). An…
Twig or Pug/Jade are the best ones I've seen. C#'s Razor seemed pretty good too in the brief time I used it.
I tried to go the old-school route of server rendered pages. But then I thought to myself: I would need to write an API later so that's double the amount of work. What if I'm also going to make a mobile app? I can spin up a graphql API, use create-react-app, and react native, use apollo client to share lots of code and be done with it. The alternative is more "pure" I guess but it's a lot of double work.
If a mobile app needs to request the same data, simply make a .json version of the route and use that same little db access function, shove the return into res.json({}) and Tada.
Sharing ui code between react native and web-react is pointless so you'd be sharing what? some formatting functions? the request functions that the .json and ssr routes effectively return for you?
Earlier quoted context omitted.
Sure, there's lot of code to write, but is the end goal writing code, or making a web app that's great for users?
Not sure I get what your comment is saying, but: > making a web app that's great for users That's what the goal is, and that's what SPAs enable. You can't build a modern web app without it being a SPA. The two are basically synonymous, I don't understand how there is even a discussion around this. No user wants to navigate to another page and lose their context. That's why the industry moved to SPAs. If you ever trie…
This erroneous belief is the very source of the problem. Here's a user, telling you that I'm sick of lag from weird multistage loads in apps that gain nothing from keeping local state in browser JavaScript variables.
I have never, literally never, thought that a good experience came from a SPA. Give me HN and it's 2000s dead simple tech any day. Or compare the absolute shit-show of new Reddit in an SPA to old Reddit.
Managing complex UI state is the problem.
Earlier quoted context omitted.
Yep. We recently did an assessment of available UI libraries and pretty much concluded the best maintained libraries with a modern look and feel are all web-focused and we're likely to have to settle for building an electron app if we want to be able to take advantage of the best selection of 3rd party libraries without building as much ourselves. As much as I don't like the ecosystem or Javascript as a language, the…
Hi, I'm a Redux maintainer. Note that we have considerably changed the Redux patterns that we teach over the last couple years to make it easier for folks to learn and use Redux. We now teach using our Redux Toolkit package as the default way to write Redux logic [0], and the React-Redux hooks API [1] as the standard way to work with Redux in React components. We recently rewrote our tutorials from scratch [2], and o…
Earlier quoted context omitted.
> The starting point for doing anything with React is where you call it to render a certain component at a certain point in your document You're trying to use the literal meaning of "you call it" to make an argument but that argument doesn't support the position you think it does. Yes, React has `ReactDOM.render()`, but did you know Angular.js also has an entry point called `angular.bootstrap()`? Vue has `new Vue()`…
I would say the traditional distinction between a library and a framework, to the extent that the industry has any settled definition for these terms at all, is about who dictates the application architecture and the control flow. A framework typically establishes a runtime environment and then calls into your code to respond to specific events. Common examples are GUI applications that run an event loop responding t…
IMHO, it's more fruitful to ponder the possibility that certain projects are not frameworks because they fundamentally lack something that frameworks provide. Suppose we tried to use nothing but lodash to implement a web app. It's certainly doable (given that people write vanilla apps), lodash would "permeate" the codebase and it would probably call a sizable number of your callbacks. But I think we'd both agree lodash is not a framework. But why? I'd argue it's because organizing units (in the "unit test" sense) coherently in a way that is maintainable is outside of its expressed scope. In other words, it's not suitable to that task, even if we wanted it to. React is not only suitable for it, it's specifically designed for that purpose.
Speaking of units, another way we can approach this is by looking at where unit boundaries are in comparison to user code boundaries. If you look at any usage of node's `child_process` API, the event handler functions are generally not considered units; the entire child_process instance setup might be one unit, and the event handlers may call other units that are ideally decoupled from whether callback arguments are partial Buffers or error codes and so on. Similarly, a sorting callback is not typically a unit (i.e. you never test that the callback returns 1 or -1, you test that the code sorts correctly instead). React components on the other hand are units in and of themselves. I believe it is accurate to say that frameworks provide abstractions whose purpose is to delineate where a unit boundary is. Components fit that bill perfectly, just as controllers and views and services do in other architectures.
Earlier quoted context omitted.
If you're building a desktop app, just plain C# in visual studio has an extremely powerful GUI (WinForms) that is fairly easy to use. Lots of widgets abs very good charts and graphs that you can zoom-in on and annotate in a million ways. It's miles ahead of Python (saying this as a Python guy). Click Once means installs are fairly simple (assuming a Windows deployment).
That's true, but it seems like WinForms is basically a dead end at this point, not much maintenance work is put into it and you have to jump through some serious hoops to make basic stuff like DPI scaling work even last I checked. Completely agree though, the 3rd party component story is very good on .NET, but the applications you're producing don't exactly have a modern look and feel unless you're investing serious…
The future could be MAUI though; and it is around the corner
Oh they're loved all right, it's just that they're (all three) very mature, packed with features, easy to pick up and people who work with them don't have a reason to sit around and discuss the tools.
I work for a smaller Rails shop and the atmosphere is just so nice there. We work on small (think $20k) projects for different niche customers, we absolutely reject SPAs (for what we do), we host the apps on cheap VMs, we don't worry about scaling at all, we talk to the clients a lot, we prototype fast and it's all just so easy and even brings good money.
Rails is the no-bullshit way, and definitely the human way.