4 ms·

The reasons I avoid large frameworks like React, Angular, Vue, and even jQuery is that they are aren't necessary. They are code decoration that slows things do

The reasons I avoid large frameworks like React, Angular, Vue, and even jQuery is that they are aren't necessary. They are code decoration that slows things down. Here is what you can expect without these: * greater flexibility * faster execution, My current application produces a large single page application that fully renders visually and executes state restoration in about 105ms localhost or under 200ms across a network * faster maintenance, I can do massive refactors that touch most files in the application in about 2 hours thanks to thorough use of TypeScript interface definitions --- Here is how I do it: 1. Just start building your application. Realize that for any significant application the front end UI is probably only about 20% of the application code, or less. 2. Start the UI by writing static HTML. Reserve JavaScript, in the browser, only for handling events and state restoration and execute state restoration only on page load. 3. I prefer to use WebSockets over HTTP as much as possible for absolutely everything I can get away with. WebSockets are full-duplex, where HTTP is not, and have far less overhead. That will substantially reduce the complexity around messaging in and out of the web browser. 4. Everything after that is just execution, planning, refactoring, and feature addition. 5. You can do absolutely all of it in TypeScript now without any compile step. Node.js now executes TypeScript directly, but the browser does not. To solve for the web browser just include the browser code into your Node application using ES6 module import. If the imported code is a function you can convert it directly into a string for transport, and otherwise use JSON.stringify for objects/arrays.

ramon156 1y ago
Frameworks aren't necessary in the same way that high level languages aren't necessary. It depends, it always does If you want to ship an MVP next week and you spend 6 days setting up your env, you've already failed. If you can get a framework with at least 80% of the features you need, suddenly you have 6.5 days left to build the product
- austin-cheney 1y ago
  If it takes you 6 days to set up your environment there are bigger problems than framework choice at play. It does not take more than a couple hours to fully prototype some HTML and some JavaScript/TypeScript in the backend.
mexicocitinluez 1y ago
> and even jQuery is that they are aren't necessary. JQuery was never considered "necessary". It's just a much prettier wrapper around the native dom apis. Arguing against adopting a more readable api (and codebase), is gonna be a tough sell.
- austin-cheney 1y ago
  Nobody worries about fashion when buying a shovel. Your users don't care about your code fashion. These things are clear when an outside party can observe your developer habits and inform you where your priorities are as opposed to what you state they are.
  - mexicocitinluez 1y ago
    > Nobody worries about fashion when buying a shovel. Huh? Are you implying the code will never get read by another developer or possibly modified? Are you arguing there is no reason to make your code more readable? > These things are clear when an outside party can observe your developer habits and inform you where your priorities are as opposed to what you state they are. What?
dsego 1y ago
Not sure how you avoid reinventing any of the component frameworks. Writing custom JS component backbone style seems tedious and error prone. Manually modifying the DOM on changes means writing the same logic several times, once for the initial render and then repeated in every event handler that has change the state of the UI. Alternatively, you might just be nuking your DOM with inner html and then running everything again through the initial rendering logic. But this isn't ideal, components loose focus, there can be glitches, and it can get slow. Not sure how you could make the type of complex UI heavy apps and have any greater flexibility or faster maintenance.
- thomasikzelf 1y ago
  If you are writing the same DOM update code in each event handler you can abstract it into a function.
  - dsego 1y ago
    What I'm saying, say you have 3 dependent dropdown pickers, selecting an item in the first one determine which of the other 2 are shown. When you have reactive interfaces like that, it's hard to extract the common "business" logic. Either you redraw everything from scratch or you do a sort of show/hide on DOM elements as in jQuery days. Not sure how you can abstract that. If you do abstract it, you end up with backbone, vue, react, or other in any case.
    - austin-cheney 1y ago
      You are still thinking in terms of framework goodness, which is why this is challenging for you. Don't do that. Don't redraw anything. Don't create some shallow copy, cloned node, or other insanity. You don't need any of that. You don't need to litter your code, most especially your DOM nodes, with a bunch of business logic insanity. All you need is the event handler. The event handler can be assigned to a node's event property directly, but if this is for a commercial site with lots of third party analytics/spyware you need to use a event listener instead because those third party libraries will overwrite your event assignments. The event handler receives an event object as an argument with a reference back to the given DOM node. All the business logic should be stored in a single location representing a given business function, typically far away from the browser logic. It makes sense when you write the code without using a framework. If you write the code and try to make it look like a framework it will look like a framework, unsurprisingly. If you don't do a bunch of framework component insanity it will not look like a framework. This is a person problem, not a technology problem.
iamcreasy 1y ago
> To solve for the web browser just include the browser code into your Node application using ES6 module import. I don't follow. How do you include the browser code without the compiling step?

ramon156 1y ago

Frameworks aren't necessary in the same way that high level languages aren't necessary. It depends, it always does If you want to ship an MVP next week and you spend 6 days setting up your env, you've already failed. If you can get a framework with at least 80% of the features you need, suddenly you have 6.5 days left to build the product

austin-cheney 1y ago
If it takes you 6 days to set up your environment there are bigger problems than framework choice at play. It does not take more than a couple hours to fully prototype some HTML and some JavaScript/TypeScript in the backend.

mexicocitinluez 1y ago

> and even jQuery is that they are aren't necessary. JQuery was never considered "necessary". It's just a much prettier wrapper around the native dom apis. Arguing against adopting a more readable api (and codebase), is gonna be a tough sell.

austin-cheney 1y ago
Nobody worries about fashion when buying a shovel. Your users don't care about your code fashion. These things are clear when an outside party can observe your developer habits and inform you where your priorities are as opposed to what you state they are.
- mexicocitinluez 1y ago
  > Nobody worries about fashion when buying a shovel. Huh? Are you implying the code will never get read by another developer or possibly modified? Are you arguing there is no reason to make your code more readable? > These things are clear when an outside party can observe your developer habits and inform you where your priorities are as opposed to what you state they are. What?

dsego 1y ago

Not sure how you avoid reinventing any of the component frameworks. Writing custom JS component backbone style seems tedious and error prone. Manually modifying the DOM on changes means writing the same logic several times, once for the initial render and then repeated in every event handler that has change the state of the UI. Alternatively, you might just be nuking your DOM with inner html and then running everything again through the initial rendering logic. But this isn't ideal, components loose focus, there can be glitches, and it can get slow. Not sure how you could make the type of complex UI heavy apps and have any greater flexibility or faster maintenance.

thomasikzelf 1y ago
If you are writing the same DOM update code in each event handler you can abstract it into a function.
- dsego 1y ago
  What I'm saying, say you have 3 dependent dropdown pickers, selecting an item in the first one determine which of the other 2 are shown. When you have reactive interfaces like that, it's hard to extract the common "business" logic. Either you redraw everything from scratch or you do a sort of show/hide on DOM elements as in jQuery days. Not sure how you can abstract that. If you do abstract it, you end up with backbone, vue, react, or other in any case.
  - austin-cheney 1y ago
    You are still thinking in terms of framework goodness, which is why this is challenging for you. Don't do that. Don't redraw anything. Don't create some shallow copy, cloned node, or other insanity. You don't need any of that. You don't need to litter your code, most especially your DOM nodes, with a bunch of business logic insanity. All you need is the event handler. The event handler can be assigned to a node's event property directly, but if this is for a commercial site with lots of third party analytics/spyware you need to use a event listener instead because those third party libraries will overwrite your event assignments. The event handler receives an event object as an argument with a reference back to the given DOM node. All the business logic should be stored in a single location representing a given business function, typically far away from the browser logic. It makes sense when you write the code without using a framework. If you write the code and try to make it look like a framework it will look like a framework, unsurprisingly. If you don't do a bunch of framework component insanity it will not look like a framework. This is a person problem, not a technology problem.

iamcreasy 1y ago

> To solve for the web browser just include the browser code into your Node application using ES6 module import. I don't follow. How do you include the browser code without the compiling step?