10 ms·

Wow. The author is speaking about Javascript front-end frameworks. I'm an old guy now, and I've rarely seen a need for a front-end framework. I know that sound

Wow. The author is speaking about Javascript front-end frameworks. I'm an old guy now, and I've rarely seen a need for a front-end framework. I know that sounds like heresy. I've never bothered to learn Angular, React, NextJS, Svelte or any of the alphabet soup named frameworks. Normal javascript works fine these days for a sprinkling of front-end interactivity. jQuery is not even necessary anymore. And with more recent technologies like Phoenix LiveView, there is very little need to use any of those front-end frameworks. Count me as old-fashioned, but very few apps really need those kinds of frameworks. They could mostly do without them. Frameworks are mostly necessary on the backend.

nicoburns 5y ago
> And with more recent technologies like Phoenix LiveView, there is very little need to use any of those front-end frameworks. I think I'd argue that Phoenix LiveView is a frontend framework. Albeit a non-traditional one.
black3r 5y ago
> Normal javascript works fine these days for a sprinkling of front-end interactivity. jQuery is not even necessary anymore. If you just need a sprinkling of front-end interactivity, you don't need a framework and you never needed it. If you're building a web application with lots of features, re-used components, complex data structures, etc., a framework helps you a lot. And the web today is full of complex web applications, since most of what used to be desktop applications 15 years ago are now web applications.
- sidlls 5y ago
  This is true. The question is whether it's necessary or good (for consumers, for businesses, for the software engineering profession, etc.). The answer is subjective and lies within a spectrum, surely, but I tend toward the negative end of that spectrum. I don't believe the complexity in web applications is good (for anyone, except possibly browser makers, front-end developers and framework makers) and therefore it's not really necessary. The browser today is mostly a terrible, inefficient, and limited functionality VM over the host OS, and that provides an inconsistent user experience across devices and even minor browser versions. What I've seen over the last 20 years of my lifetime has been an unfolding of a sort of tragedy of the commons in this context. We have a seeming endless supply of computational resources, "everyone" wants to exploit it in the most ruthless way possible, and it has lead to a deplorable state in the industry where bad practices and inefficiencies are not only tolerated but sought (for resume building, fast releases, whatever), and ultimately it results in terrible abuse/misuse of the resources we have.
  - 7sidedmarble 5y ago
    Well not everyone is building websites on the web. Building an app for the web is not some horrible thing. Google docs, sheets, etc are all perfect examples of the kinds of apps suited to the web: ones that benefit from the ability to be accessed from anywhere on any device, and encourage collaboration.
    - deleted 5y ago
      [deleted]
    - sidlls 5y ago
      We had this functionality before web apps were a thing. I'm not going to claim it was some golden era/glory days in a bug-free, seamless cross-device nirvana, but it's not like it was a wasteland, either. And for all the promise of cheaper, better apps that the webapp paradigm has been suggested to bring, we still pay a lot for armies of developers to write this stuff, and it's almost uniformly worse in both quality and feature completeness.
      - mattgreenrocks 5y ago
        Yeah, this is the most damning thing. It’s clear that the web platform seems to resist being tamed with our current tooling. Adding more devs doesn’t fix it. As time goes on I become more skeptical that tooling can even fix it. The impedance mismatch of a document viewer being made into a general app platform has yet to be truly overcome. All web apps try to eke out a living in the shadow of this. That it seems to be everywhere these days is more a function of economics than anything else.
        datavirtue 5y ago
        Winner!!
  - ozim 5y ago
    It is necessary and good. We are re-implementing complex "excel apps" into web applications. Amount of money I have seen lost because people were using different versions of excel sheets that were not up to date is staggering. Users expect full interactivity and instant calculations as they change values (just like in excel), doing it with "posting forms to back-end and recalculating" will not sell at all because it will be worse UX than excel. Having complex calculations over multiple fields require use of framework because making it with vanilla js is just pain with no MVVM and observables and two way bindings. Then of course if you have web app you have one database all your employees are working on and all price items can be updated easily in some admin panel for every new customer.
- austincheney 5y ago
  https://github.com/prettydiff/share-file-systems https://github.com/prettydiff/share-file-systems That is my application that creates an OS GUI in the browser. Plenty of features with o framework. * Code size (on the front-end) 2mb unminified. * Load time in the browser (including state restoration) about 120ms. * The first version took 15 days to write from scratch. When people claim there MUST be a framework its clear they have no idea what they are talking about. It is clearly a case of Dunning-Kruger effect where they can compare their experience with frameworks on one hand... and they have nothing to compare it to, because its all they know.
  - codemonkey-zeta 5y ago
    First of all, this is awesome! That being said, this project is not "0 framework". You built a framework from scratch to suit the application.
    - Supermancho 5y ago
      > That being said, this project is not "0 framework". You built a framework from scratch to suit the application. That depends on how you define framework. By this definition, any computer program has an inherent framework and the term loses it's meaning altogether. This project does not include an opinionated methodology or ideology on how to design features. There is no template nor scaffolding to plan out commonly implemented features. There is no way to estimate work for new unique functionality. There is no framework here, afaict.
  - pkphilip 5y ago
    This is really nice! Congratulations! I am surprised that this isn't more famous. One comment though: please have your video in Full HD format rather than 4k. Most people don't use 4K and so it is difficult to see your product demo. And yes, I agree with you completely. There is really no need to use all of the fancy frameworks - plain vanilla js can give you quite a bit of power to build products like the one you made.
    - 5y ago
- itronitron 5y ago
  No, you still don't need a web UI framework for rich front-end interactivity. That assumes however that your developers know how to write a callback function.
  - onion2k 5y ago
    "You don't need a framework" assumes your developers will write code that operates with everyone else's code nicely, without accidently writing something that will be painful to remove in a year's time. Frameworks generally enforce a pattern where things are quite well encapsulated, don't pollute global spaces, don't mess with prototypes, and manage callbacks well. Code written by one person, or a group of well-organised experts, also does that, but as soon as you have a less talented team, or a couple of juniors who aren't being overseen because the seniors are too busy, things creep in to the code that have the potential to blow up later. Frameworks help your team avoid those footguns (and introduce some different ones, but at least they're usually easier to manage).
    - 6510 5y ago
      but then the juniors never become the experts
      - datavirtue 5y ago
        They become managers long before that happens.
    - mattgreenrocks 5y ago
      Maybe the idea of throwing a bunch of junior devs at something is suspect to begin with?
  - orcasushi 5y ago
    Yes true! I once had the honour to work with a 'tech-lead' dev that rewrote a whole map application to AngularJS, which was the hype back then. I remember him not being able to get a just slightly complicated chain of asynchronous stuff working in vanillaJS. No problem, because he had AngularJS double binding now. No need to learn vanillaJS. Wicked stuff.
- jdrc 5y ago
  > most of what used to be desktop applications 15 years ago are now web applications. and that was a choice
  - dotancohen 5y ago
    That was a choice that very few of us made but we all have to live with. Such is life.
jesselawson 5y ago
My favorite front-end framework is [VanillaJs](http://vanilla-js.com/ http://vanilla-js.com/).
- croes 5y ago
  Is it open source?
  - cto_of_antifa 5y ago
- throwaway_4ever 5y ago
  removed
  - teg4n_ 5y ago
    That is literally what the site is about.
dewey 5y ago
> Count me as old-fashioned, but very few apps really need those kinds of frameworks. They could mostly do without them. Probably true if you look at it in a vacuum. I think if there's a big team a framework is certainly helpful to keep thing's organized and the borders a bit more defined. You also benefit from a community, best practises and documentation about how things should be structured and work.
- hackerfromthefu 5y ago
  Frameworks are more valuable if you have to work with junior developers.
amelius 5y ago
Modern frameworks help to separate state from code. And also to reduce the amount of work in case of a state update. For large applications (or small ones that may grow large one day), you absolutely need a framework.
- jonhohle 5y ago
  Yeah, it’s not like anything ever got done before heavyweight front end frameworks /s
GordonS 5y ago
Another old'ish guy here, and I feel the same way. I have done a few projects using Knockout and Angular, and I've used Svelte a little too. My conclusion is that SPAs definitely have their place - but that place is in the minority, mostly for web apps with complex UI/UX. In SSR (Server-Side Rendered) projects (typically ASP.NET Core for me nowadays, but I've used others too), things are just so much simpler, with fewer moving parts. A sprinkling of JavaScript is all that's needed, and even then a lot is reusable between projects. And now IE has finally died, jQuery is no longer needed, and browser support for ES6 is good, even writing JavaScript is less miserable than it used to be.
- deleted 5y ago
  [deleted]
- zdragnar 5y ago
  Is it not simpler because the applications themselves are simpler? I mean, when you say that client frameworks like angular and svelte have their place with complex UX/UI interactions. Of course SSR is simpler- request in, send / receive from a database, markup out. It isnt anything to do with SSR- your domain is simpler.
  - _9omd 5y ago
    > your domain is simpler This echos my thinking whenever these framework/SSR/JavaScript debates come up. It's like everyone is talking past each other because there is no clarity around the complexity of what's being built.
    - stepbeek 5y ago
      I use miro and figma as examples of products that would be extremely hard to build as a traditional SSR app.
  - naasking 5y ago
    > your domain is simpler. So you're saying the domain is simpler while still satisfying the client's requirements? I think that's exactly the OP's point.
deleted 5y ago
[deleted]
ralusek 5y ago
> I've rarely seen a need for a front-end framework. I know that sounds like heresy. No it sounds like the comments on every post on HN remotely related to JS. > I've never bothered to learn Angular, React, NextJS, Svelte or any of the alphabet soup named frameworks That makes your opinion definitionally uninformed. If you had bothered to learn any of them, you would see that they have many benefits. Nobody is saying that you need any of them, but they are very useful. The single greatest advantage to using any of the frameworks, however, is that they provide a relatively definitive way of solving any of the problems that you will have to solve, building an SPA. Routing, caching, state management, reactivity, inputs...There is no way around solving these problems, so you're either going with what they've got, or reinventing the wheel. But by reinventing the wheel, you're probably going to do a worse job than the team that has spent years solving these problems, and more importantly, you're losing access to a definitive way of doing things that you (and others) can refer to. And that's the real kicker, is working with others. I worked as a contractor for years, and I can tell you the ease of jumping on a project using a front end framework vs a home baked JQuery or vanilla solution was practically immeasurably vast. Even jumping on a project using a framework I'd never heard of, but still had documentation and an online community, would have me up and running within a day or two at most.
- cto_of_antifa 5y ago
- virtualwhys 5y ago
  Your entire argument is predicated on building an SPA; if you don't need an SPA then you de facto do not need a frontend framework (which is what the OP is implicitly saying, do as much as possible server-side). Now, saying that, there is something to be said for separating UI from the backend. Yes, it adds ( a great deal of) complexity compared to server-side applications, but the reactive programming model is quite powerful, and useful even if you could build the application entirely on the server. And obviously if you do need an SPA (e.g. wrapping WebView for iOS/Android) then you don't have a choice, or if you do you'll be reinventing the wheel, poorly.
  - 5y ago
pbreit 5y ago
There’s a growing school of thought of the exact opposite: end users expect the UX that frameworks deliver and the back-end is simply an API in front of a DB.
- deleted 5y ago
  [deleted]
- ozim 5y ago
  I don't know if it is growing thought of school. I think it is just obvious direction. Take for example excel and if you change value in one cell you get all calculations in sheet updated automatically. Implement something like that without a framework and only plain js with dozens of fields having dependencies on each other, good luck :) Implement something like that with cute "recalculate" button on the bottom of 3 screen scroll and no one will use your solution.
  - interpenetrate 5y ago
    >Implement something like that without a framework and only plain js with dozens of fields having dependencies on each other, good luck :) I just implemented a complete spreadsheet solution inspired by Airtable (sticky header and columns, column resizing, virtual scrolling, row selection, cell selection, cell editing, a few cell types) in approximately 500 lines of vanilla JS. No virtual DOM, no reactive data library, no framework. Just direct DOM manipulations. It performs great and is pretty easy to understand and extend. For now, the reactive "field dependency" problem is just solved by re-rendering the entire spreadsheet when a cell is updated (really just re-rendering the visible rows, because of virtual scrolling). The state management is just not that complicated. I suggest this sort of project as an exercise if you've found yourself engrossed by this or that front-end framework. My go-to front-end frameworks for the past few years have been Mithril.js and Vue, but they really would have been a major hindrance in this case. I can't imagine Svelte or Solid.js or whatever being any better...
    - ozim 5y ago
      That is not what I am implementing. Re implementing custom app with its business rules that was buried in excel sheet is a different thing. People don't want to buy excel in a browser, because they can have that already, they want their custom logic and in a way it works in excel.
JakeAl 5y ago
I feel the same about single-page applications. Give me good old fashion static HTML and CRUD database calls on a single production server with a back-up server, development server and live-test mirror server and using 1995 hardware it could handle 250K simultaneous users easy. Things have gotten insanely bloated and big-tech dependent with a huge price tag to build and maintain.
- minifiedjs 5y ago
  This is true. I wonder how servers used to scale very well in the past.
deleted 5y ago
[deleted]
bob1029 5y ago
I find deep joy in constraining my web development toolset these days. I remember what it was like to be faced with the task of building a new website from zero, and the temptation to reach out and consume other peoples' components/code/ideas. I don't know that you could actually master the art of vanilla web dev without first taking a ride on someone else's rollercoaster a few times. > Frameworks are mostly necessary on the backend. Sounds like I might be a double-heretic now...
FpUser 5y ago
Hear hear. We have zero problems not using web frameworks for our SPAs. Just a couple of libs and we write web components here and there to solve particular tasks when needed. Using the power of modern JS I fail to see the value of things like React. Maybe it has for the orgs of FB size but I do not operate at that level. My backends are semi-stateful C++ servers with no frameworks either. Just some libs and std.
ravenstine 5y ago
> And with more recent technologies like Phoenix LiveView, there is very little need to use any of those front-end frameworks. Sure, if you choose to buy in to a backend framework. I'm not knocking Phoenix, but it's a tradeoff. I'd rather be able to write the backend without a framework and use the framework where I want to spend the least amount of time figuring things out, which is usually on the frontend/GUI. But everyone is different.
bizdatblyat 5y ago
mirekrusin 5y ago
Frameworks are mostly necessary on the backend. ...not really, we're running high stake trading application (constellation of services) without framework and it works really well. Shallow/no-dependencies is great. We've been throwing complexity at it for 4 years+ and there is no fatigue, things are crafted to fit the purpose, it works, really, really well. I get personal satisfaction from removing code necessary to do the job.
commandlinefan 5y ago
> I’ve rarely seen a need for a front-end framework I feel the same way about both front-end and back-end frameworks - or at least the sorts of things that call themselves frameworks. Struts was kind of useful in its time, but in the end didn’t save you much effort as code. Usually when people talk about Java server side frameworks these days, they mean Spring, which is worse than useless, because it actively makes development harder.
holoduke 5y ago
Frameworks van be useful in any large dev project. It can bring structure. Things like routers, http request processors, object binding, ui components and many more.
6510 5y ago
While I agree, I always use vanilla (never used jquery either) but I don't do opinions about things I'm not familiar with. No doubt all the framework research produced useful abstractions that we now have in js or should have.
whiddershins 5y ago
Sveltekit deployed to vercel and you might need no back end at all, much less a framework, and come away with a fast single page app with fast dev iteration speed.
tootie 5y ago
I think a huge part of the value frameworks bring is a common vocabulary. Whether or not it makes it easier to write code might be debatable, but it absolutely help scales communication and decision-making. Everyone in your org building UI components knows what the expectation is. And new joiners can be onboarded quickly if they have experience. Using a framework and a strict linter is probably a tax on productivity when it comes to churning out code, but it's a major booster to the time it takes to understand code written by someone else.
deleted 5y ago
[deleted]
zmix 5y ago
> Frameworks are mostly necessary on the backend. Often not even there! If you use something like BaseX[1] or eXist-db[2], both XML database and XQuery[3] implementations (they also have ways to act as SQL clients), you get REST-, user-, and database-management as native part of the programming language (XQuery). For REST it must implement the RESTXQ[4] module standard, which both the named products do. Since XQuery understands XML natively, you get full templating, database queries, REST routing and much more. [1] https://basex.org https://basex.org [2] https://exist-db.org https://exist-db.org [3] https://en.wikipedia.org/wiki/XQuery https://en.wikipedia.org/wiki/XQuery [4] https://www.google.com/search?q=restxq https://www.google.com/search?q=restxq
- dotancohen 5y ago
  This sounds like giving the client direct access to the database. Sounds like a great way to facilitate data exfiltration attacks.

nicoburns 5y ago

> And with more recent technologies like Phoenix LiveView, there is very little need to use any of those front-end frameworks. I think I'd argue that Phoenix LiveView is a frontend framework. Albeit a non-traditional one.

black3r 5y ago

> Normal javascript works fine these days for a sprinkling of front-end interactivity. jQuery is not even necessary anymore. If you just need a sprinkling of front-end interactivity, you don't need a framework and you never needed it. If you're building a web application with lots of features, re-used components, complex data structures, etc., a framework helps you a lot. And the web today is full of complex web applications, since most of what used to be desktop applications 15 years ago are now web applications.

sidlls 5y ago
This is true. The question is whether it's necessary or good (for consumers, for businesses, for the software engineering profession, etc.). The answer is subjective and lies within a spectrum, surely, but I tend toward the negative end of that spectrum. I don't believe the complexity in web applications is good (for anyone, except possibly browser makers, front-end developers and framework makers) and therefore it's not really necessary. The browser today is mostly a terrible, inefficient, and limited functionality VM over the host OS, and that provides an inconsistent user experience across devices and even minor browser versions. What I've seen over the last 20 years of my lifetime has been an unfolding of a sort of tragedy of the commons in this context. We have a seeming endless supply of computational resources, "everyone" wants to exploit it in the most ruthless way possible, and it has lead to a deplorable state in the industry where bad practices and inefficiencies are not only tolerated but sought (for resume building, fast releases, whatever), and ultimately it results in terrible abuse/misuse of the resources we have.
- 7sidedmarble 5y ago
  Well not everyone is building websites on the web. Building an app for the web is not some horrible thing. Google docs, sheets, etc are all perfect examples of the kinds of apps suited to the web: ones that benefit from the ability to be accessed from anywhere on any device, and encourage collaboration.
  - deleted 5y ago
    [deleted]
  - sidlls 5y ago
    We had this functionality before web apps were a thing. I'm not going to claim it was some golden era/glory days in a bug-free, seamless cross-device nirvana, but it's not like it was a wasteland, either. And for all the promise of cheaper, better apps that the webapp paradigm has been suggested to bring, we still pay a lot for armies of developers to write this stuff, and it's almost uniformly worse in both quality and feature completeness.
    - mattgreenrocks 5y ago
      Yeah, this is the most damning thing. It’s clear that the web platform seems to resist being tamed with our current tooling. Adding more devs doesn’t fix it. As time goes on I become more skeptical that tooling can even fix it. The impedance mismatch of a document viewer being made into a general app platform has yet to be truly overcome. All web apps try to eke out a living in the shadow of this. That it seems to be everywhere these days is more a function of economics than anything else.
      - datavirtue 5y ago
        Winner!!
- ozim 5y ago
  It is necessary and good. We are re-implementing complex "excel apps" into web applications. Amount of money I have seen lost because people were using different versions of excel sheets that were not up to date is staggering. Users expect full interactivity and instant calculations as they change values (just like in excel), doing it with "posting forms to back-end and recalculating" will not sell at all because it will be worse UX than excel. Having complex calculations over multiple fields require use of framework because making it with vanilla js is just pain with no MVVM and observables and two way bindings. Then of course if you have web app you have one database all your employees are working on and all price items can be updated easily in some admin panel for every new customer.
austincheney 5y ago
https://github.com/prettydiff/share-file-systems https://github.com/prettydiff/share-file-systems That is my application that creates an OS GUI in the browser. Plenty of features with o framework. * Code size (on the front-end) 2mb unminified. * Load time in the browser (including state restoration) about 120ms. * The first version took 15 days to write from scratch. When people claim there MUST be a framework its clear they have no idea what they are talking about. It is clearly a case of Dunning-Kruger effect where they can compare their experience with frameworks on one hand... and they have nothing to compare it to, because its all they know.
- codemonkey-zeta 5y ago
  First of all, this is awesome! That being said, this project is not "0 framework". You built a framework from scratch to suit the application.
  - Supermancho 5y ago
    > That being said, this project is not "0 framework". You built a framework from scratch to suit the application. That depends on how you define framework. By this definition, any computer program has an inherent framework and the term loses it's meaning altogether. This project does not include an opinionated methodology or ideology on how to design features. There is no template nor scaffolding to plan out commonly implemented features. There is no way to estimate work for new unique functionality. There is no framework here, afaict.
- pkphilip 5y ago
  This is really nice! Congratulations! I am surprised that this isn't more famous. One comment though: please have your video in Full HD format rather than 4k. Most people don't use 4K and so it is difficult to see your product demo. And yes, I agree with you completely. There is really no need to use all of the fancy frameworks - plain vanilla js can give you quite a bit of power to build products like the one you made.
  - 5y ago
itronitron 5y ago
No, you still don't need a web UI framework for rich front-end interactivity. That assumes however that your developers know how to write a callback function.
- onion2k 5y ago
  "You don't need a framework" assumes your developers will write code that operates with everyone else's code nicely, without accidently writing something that will be painful to remove in a year's time. Frameworks generally enforce a pattern where things are quite well encapsulated, don't pollute global spaces, don't mess with prototypes, and manage callbacks well. Code written by one person, or a group of well-organised experts, also does that, but as soon as you have a less talented team, or a couple of juniors who aren't being overseen because the seniors are too busy, things creep in to the code that have the potential to blow up later. Frameworks help your team avoid those footguns (and introduce some different ones, but at least they're usually easier to manage).
  - 6510 5y ago
    but then the juniors never become the experts
    - datavirtue 5y ago
      They become managers long before that happens.
  - mattgreenrocks 5y ago
    Maybe the idea of throwing a bunch of junior devs at something is suspect to begin with?
- orcasushi 5y ago
  Yes true! I once had the honour to work with a 'tech-lead' dev that rewrote a whole map application to AngularJS, which was the hype back then. I remember him not being able to get a just slightly complicated chain of asynchronous stuff working in vanillaJS. No problem, because he had AngularJS double binding now. No need to learn vanillaJS. Wicked stuff.
jdrc 5y ago
> most of what used to be desktop applications 15 years ago are now web applications. and that was a choice
- dotancohen 5y ago
  That was a choice that very few of us made but we all have to live with. Such is life.

jesselawson 5y ago

My favorite front-end framework is [VanillaJs](http://vanilla-js.com/ http://vanilla-js.com/).

croes 5y ago
Is it open source?
- cto_of_antifa 5y ago
throwaway_4ever 5y ago
removed
- teg4n_ 5y ago
  That is literally what the site is about.

dewey 5y ago

> Count me as old-fashioned, but very few apps really need those kinds of frameworks. They could mostly do without them. Probably true if you look at it in a vacuum. I think if there's a big team a framework is certainly helpful to keep thing's organized and the borders a bit more defined. You also benefit from a community, best practises and documentation about how things should be structured and work.

hackerfromthefu 5y ago
Frameworks are more valuable if you have to work with junior developers.

amelius 5y ago

Modern frameworks help to separate state from code. And also to reduce the amount of work in case of a state update. For large applications (or small ones that may grow large one day), you absolutely need a framework.

jonhohle 5y ago
Yeah, it’s not like anything ever got done before heavyweight front end frameworks /s

GordonS 5y ago

Another old'ish guy here, and I feel the same way. I have done a few projects using Knockout and Angular, and I've used Svelte a little too. My conclusion is that SPAs definitely have their place - but that place is in the minority, mostly for web apps with complex UI/UX. In SSR (Server-Side Rendered) projects (typically ASP.NET Core for me nowadays, but I've used others too), things are just so much simpler, with fewer moving parts. A sprinkling of JavaScript is all that's needed, and even then a lot is reusable between projects. And now IE has finally died, jQuery is no longer needed, and browser support for ES6 is good, even writing JavaScript is less miserable than it used to be.

deleted 5y ago
[deleted]
zdragnar 5y ago
Is it not simpler because the applications themselves are simpler? I mean, when you say that client frameworks like angular and svelte have their place with complex UX/UI interactions. Of course SSR is simpler- request in, send / receive from a database, markup out. It isnt anything to do with SSR- your domain is simpler.
- _9omd 5y ago
  > your domain is simpler This echos my thinking whenever these framework/SSR/JavaScript debates come up. It's like everyone is talking past each other because there is no clarity around the complexity of what's being built.
  - stepbeek 5y ago
    I use miro and figma as examples of products that would be extremely hard to build as a traditional SSR app.
- naasking 5y ago
  > your domain is simpler. So you're saying the domain is simpler while still satisfying the client's requirements? I think that's exactly the OP's point.

deleted 5y ago

[deleted]

ralusek 5y ago

> I've rarely seen a need for a front-end framework. I know that sounds like heresy. No it sounds like the comments on every post on HN remotely related to JS. > I've never bothered to learn Angular, React, NextJS, Svelte or any of the alphabet soup named frameworks That makes your opinion definitionally uninformed. If you had bothered to learn any of them, you would see that they have many benefits. Nobody is saying that you need any of them, but they are very useful. The single greatest advantage to using any of the frameworks, however, is that they provide a relatively definitive way of solving any of the problems that you will have to solve, building an SPA. Routing, caching, state management, reactivity, inputs...There is no way around solving these problems, so you're either going with what they've got, or reinventing the wheel. But by reinventing the wheel, you're probably going to do a worse job than the team that has spent years solving these problems, and more importantly, you're losing access to a definitive way of doing things that you (and others) can refer to. And that's the real kicker, is working with others. I worked as a contractor for years, and I can tell you the ease of jumping on a project using a front end framework vs a home baked JQuery or vanilla solution was practically immeasurably vast. Even jumping on a project using a framework I'd never heard of, but still had documentation and an online community, would have me up and running within a day or two at most.

cto_of_antifa 5y ago
virtualwhys 5y ago
Your entire argument is predicated on building an SPA; if you don't need an SPA then you de facto do not need a frontend framework (which is what the OP is implicitly saying, do as much as possible server-side). Now, saying that, there is something to be said for separating UI from the backend. Yes, it adds ( a great deal of) complexity compared to server-side applications, but the reactive programming model is quite powerful, and useful even if you could build the application entirely on the server. And obviously if you do need an SPA (e.g. wrapping WebView for iOS/Android) then you don't have a choice, or if you do you'll be reinventing the wheel, poorly.
- 5y ago

pbreit 5y ago

There’s a growing school of thought of the exact opposite: end users expect the UX that frameworks deliver and the back-end is simply an API in front of a DB.

deleted 5y ago
[deleted]
ozim 5y ago
I don't know if it is growing thought of school. I think it is just obvious direction. Take for example excel and if you change value in one cell you get all calculations in sheet updated automatically. Implement something like that without a framework and only plain js with dozens of fields having dependencies on each other, good luck :) Implement something like that with cute "recalculate" button on the bottom of 3 screen scroll and no one will use your solution.
- interpenetrate 5y ago
  >Implement something like that without a framework and only plain js with dozens of fields having dependencies on each other, good luck :) I just implemented a complete spreadsheet solution inspired by Airtable (sticky header and columns, column resizing, virtual scrolling, row selection, cell selection, cell editing, a few cell types) in approximately 500 lines of vanilla JS. No virtual DOM, no reactive data library, no framework. Just direct DOM manipulations. It performs great and is pretty easy to understand and extend. For now, the reactive "field dependency" problem is just solved by re-rendering the entire spreadsheet when a cell is updated (really just re-rendering the visible rows, because of virtual scrolling). The state management is just not that complicated. I suggest this sort of project as an exercise if you've found yourself engrossed by this or that front-end framework. My go-to front-end frameworks for the past few years have been Mithril.js and Vue, but they really would have been a major hindrance in this case. I can't imagine Svelte or Solid.js or whatever being any better...
  - ozim 5y ago
    That is not what I am implementing. Re implementing custom app with its business rules that was buried in excel sheet is a different thing. People don't want to buy excel in a browser, because they can have that already, they want their custom logic and in a way it works in excel.

JakeAl 5y ago

I feel the same about single-page applications. Give me good old fashion static HTML and CRUD database calls on a single production server with a back-up server, development server and live-test mirror server and using 1995 hardware it could handle 250K simultaneous users easy. Things have gotten insanely bloated and big-tech dependent with a huge price tag to build and maintain.

minifiedjs 5y ago
This is true. I wonder how servers used to scale very well in the past.

deleted 5y ago

[deleted]

bob1029 5y ago

I find deep joy in constraining my web development toolset these days. I remember what it was like to be faced with the task of building a new website from zero, and the temptation to reach out and consume other peoples' components/code/ideas. I don't know that you could actually master the art of vanilla web dev without first taking a ride on someone else's rollercoaster a few times. > Frameworks are mostly necessary on the backend. Sounds like I might be a double-heretic now...

FpUser 5y ago

Hear hear. We have zero problems not using web frameworks for our SPAs. Just a couple of libs and we write web components here and there to solve particular tasks when needed. Using the power of modern JS I fail to see the value of things like React. Maybe it has for the orgs of FB size but I do not operate at that level. My backends are semi-stateful C++ servers with no frameworks either. Just some libs and std.

ravenstine 5y ago

> And with more recent technologies like Phoenix LiveView, there is very little need to use any of those front-end frameworks. Sure, if you choose to buy in to a backend framework. I'm not knocking Phoenix, but it's a tradeoff. I'd rather be able to write the backend without a framework and use the framework where I want to spend the least amount of time figuring things out, which is usually on the frontend/GUI. But everyone is different.

bizdatblyat 5y ago

mirekrusin 5y ago

Frameworks are mostly necessary on the backend. ...not really, we're running high stake trading application (constellation of services) without framework and it works really well. Shallow/no-dependencies is great. We've been throwing complexity at it for 4 years+ and there is no fatigue, things are crafted to fit the purpose, it works, really, really well. I get personal satisfaction from removing code necessary to do the job.

commandlinefan 5y ago

> I’ve rarely seen a need for a front-end framework I feel the same way about both front-end and back-end frameworks - or at least the sorts of things that call themselves frameworks. Struts was kind of useful in its time, but in the end didn’t save you much effort as code. Usually when people talk about Java server side frameworks these days, they mean Spring, which is worse than useless, because it actively makes development harder.

holoduke 5y ago

Frameworks van be useful in any large dev project. It can bring structure. Things like routers, http request processors, object binding, ui components and many more.

6510 5y ago

While I agree, I always use vanilla (never used jquery either) but I don't do opinions about things I'm not familiar with. No doubt all the framework research produced useful abstractions that we now have in js or should have.

whiddershins 5y ago

Sveltekit deployed to vercel and you might need no back end at all, much less a framework, and come away with a fast single page app with fast dev iteration speed.

tootie 5y ago

I think a huge part of the value frameworks bring is a common vocabulary. Whether or not it makes it easier to write code might be debatable, but it absolutely help scales communication and decision-making. Everyone in your org building UI components knows what the expectation is. And new joiners can be onboarded quickly if they have experience. Using a framework and a strict linter is probably a tax on productivity when it comes to churning out code, but it's a major booster to the time it takes to understand code written by someone else.

deleted 5y ago

[deleted]

zmix 5y ago

> Frameworks are mostly necessary on the backend. Often not even there! If you use something like BaseX[1] or eXist-db[2], both XML database and XQuery[3] implementations (they also have ways to act as SQL clients), you get REST-, user-, and database-management as native part of the programming language (XQuery). For REST it must implement the RESTXQ[4] module standard, which both the named products do. Since XQuery understands XML natively, you get full templating, database queries, REST routing and much more. [1] https://basex.org https://basex.org [2] https://exist-db.org https://exist-db.org [3] https://en.wikipedia.org/wiki/XQuery https://en.wikipedia.org/wiki/XQuery [4] https://www.google.com/search?q=restxq https://www.google.com/search?q=restxq

dotancohen 5y ago
This sounds like giving the client direct access to the database. Sounds like a great way to facilitate data exfiltration attacks.