26 ms·

I stopped guys, I stopped doing it. For internal tools at my company, I just use a golang backend (because most of our services are golang so there's no learnin

I stopped guys, I stopped doing it. For internal tools at my company, I just use a golang backend (because most of our services are golang so there's no learning curve for folks) and use go's templating system to render HTML. I can crank out tools in minutes. No complicated build systems or web pack or dependency management system. No react, no reduce, no apollo or graphql. No typescript, etc. Just simple go, html, css, and a bit of javascript when it's needed for a form. I don't minimize anything, or try to do anything fancy. It faster to develop in, and faster to load in the browser. I'm specifically talking about internal tools here.

loeber 4y ago
Agreed. I like this blog post on the topic, from a startup moving from React to Vanilla JS and HTML: https://www.getwaitlist.com/blog/react-to-vanillajs https://www.getwaitlist.com/blog/react-to-vanillajs
lprd 4y ago
This is the way, and should honestly be the default unless you are 100% your software needs something like an SPA.
- revskill 4y ago
  That small "unless" might require a full rewrite your application.
  - zelphirkalt 4y ago
    Well, it does require some though about SPA or website upfront, but will save lots of work and time to being online. I guess we can at least demand that much thought about things, instead of jumping immediately to SPA and causing weeks and months of more work. I have seen it. It is all "But React has this built in!" and "React does this nicely!" until it comes to actually implementing components. Without a need for interactive widgets to avoid page reloads and avoiding becoming a non-SPA again, it will take a lot more time to get things done with React, that it would take to simply churn out server-side rendered templates the traditional way. UIs that could have been done in 2 weeks the traditional way take suddenly multiple frontend devs a few months, with things like the back button not working correctly.
  - jiriknesl 4y ago
    You could use the same argument for everything. Small "unless" and you are forced to make all your APIs generic because there might be many clients. Small "unless" and you'll ignore all power features of your database and dumb-down your approach to data because user might want to switch a database. Small "unless" and you will make your app ultrascalable even when you have no proof there'll ever be more than 100 users. This is a disease that makes development slower and more expensive even when 95% of time, the customer needed something fast and cheap. No, most devs aren't building another GMail, most devs are building something that could have been modelled in 2 weeks in Visual FoxPro 25 years ago.
realmod 4y ago
> a bit of javascript when it's needed for a form. Until you get told to implement more reactive features, then it's over. Using Pure JS/JQuery for reactiveness is outright horrible.
- phendrenad2 4y ago
  What do you mean by "reactiveness"?
  - dhritzkiv 4y ago
    Updating the UI in response to user value input and state changes in real time: error messaging, validation, presenting more relevant additional inputs, formatting, etc.
    - cvdub 4y ago
      How much of a usability win is making things “real time?” Submitting a form and having the server do validation and render the error messages can feel just as fast. Plus, if you use the correct HTML input types the browser will handle the most obvious validation without any JS. You have to do validation on the server anyway. Why do it again on the front end?
      - wokwokwok 4y ago
        haha... Have you ever worked with a product manager? (: Sorry, those turn up as 'must have' features in like, meeting #2 with the product owner, because the UI feels old and rubbish without them. Technically? You're 100% right. ...but, I guarantee that even a LOB app, this will turn up, again and again and again as a feature request, until it becomes a tier 1 priority.
        saurik 4y ago
        This clearly seems to read as a problem with the "product manager", not the technology.
phailhaus 4y ago
> Just simple go, html, css, and a bit of javascript when it's needed for a form I mean if your tools are that simple, this is a no-brainer. The problem is when you have to scale up. Internal tools can get complicated because their user base is often highly specialized technical users. Managing reusable components, behavior, and state of a complex application is when you need something like React.
- danielheath 4y ago
  Scale isn’t the problem, the product need for instant (client-side) reactivity is.
  - tshaddox 4y ago
    I think the commenter is referring to the scale of functionality. Perhaps a better term would be scope.
    - danielheath 4y ago
      Right, but (eg) ERP tools have heaps of scope and very little need for client side reactivity.
  - irrational 4y ago
    Instant? Most React sites I’ve visited feel anything but instant.
    - mrkeen 4y ago
      It's necessary but not sufficient
afavour 4y ago
I’ve grown to loathe React but your approach breaks down horribly once you start getting to a certain level of complexity. There is a reason frontend JS frameworks exist, I just wish the default wasn’t React.
- dimmke 4y ago
  It won’t be. React had its time and is now waning. The future is frameworks with no virtual DOM that are interoperable with other JS frameworks like Svelte.
- deleted 4y ago
  [deleted]
- irrational 4y ago
  Have you tried Vue? I work for a huge company (nearly 100,000 employees). We tested both React and Vue and settled on Vue. That was years ago, but we’ve had no regrets since.
  - IshKebab 4y ago
    I've used Vue. It's much worse than React. It's probably ok for very small sites but its automatic reactivity system seems almost deliberately designed to produce spaghetti code and subtle bugs. Plus it has poor Typescript support. You don't have to worry at all about type errors in TSX. That said, I'm liking Yew a lot more than React. The difficult thing with React is state management, which is why it's common to resort to immutable state (even though that's a real pain in JS), and even then React chickens out by assuming components are impure by default. Everything makes way more sense in Rust. The big downside is that Yew doesn't really have anything like Bootstrap or Blueprint yet. I mean there are ports like Yewprint (great name) but they seem to be complicated to set up and you lose the really nice simplicity of Trunk.
    - Xevi 4y ago
      > Plus it has poor Typescript support. Vue 3 has excellent Typescript support. It's even built in Typescript. What exactly are you referring to when you say that it's "poor"?
jakelazaroff 4y ago
Why not use something like Retool? IMO if you’re building internal tools from scratch like that there’s a 99% chance you’re spending too much time on them.
- interlocutor 4y ago
  Or Airforms if you don't like coding: https://airforms.com/ https://airforms.com/
paulddraper 4y ago
That works until you need something crazy like a searchable drop-down.
- cvdub 4y ago
  Is that sarcasm? It’s not hard to implement a searchable dropdown in vanilla JS.
- dham 4y ago
  select boxes are searchable by default. Just isn't obvious. You can also use a datalist
- onion2k 4y ago
  This is where a good understanding of HTML helps - you can use a fatalist instead of a select. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...
  - squeaky-clean 4y ago
    On mobile (safari) it doesn't show results as you type. You have to type your partial string and then press the dropdown selector to see the list filtered by your string.
  - robertoandred 4y ago
    And datalists are incredibly limited in functionality and styling.
    - onion2k 4y ago
      Sure, so if you need more functionality or different styling they won't work. But I suspect many devs reach for a JS searchable dropdown replacement without even bothering to ask the question of whether they really need something else.
waboremo 4y ago
Makes sense, you were creating static pages but were using a tool that is dramatically overengineered for that use case. I would've switched to Astro for that use case, mainly because you could still leverage your understanding of React/Vue/Svelte/whatever within those mostly static pages very easily, plus the markdown support is brilliant for internal tooling.
robertoandred 4y ago
I’ve never understood this bizarre superiority complex people develop for themselves because they use basic tools for basic projects.
- onion2k 4y ago
  Removing complexity where you can is a good thing. Being able to recognize when you don't need a complex system is a skill. Many devs fall into the "One tool for every problem" trap by defaulting to the same boilerplate project for everything (eg create-React-app or Next.JS) and end up making something complex when a much simpler system would have worked better. If you have a basic project the tools should be basic.
  - robertoandred 4y ago
    And if you don't have a basic project, why should you stick with basic tools just to enforce some smug sense of superiority?
    - onion2k 4y ago
      Your tools should be as complex as they need to be. For most apps, that is a lot simpler than the developer has made them. The inverse isn't true because as soon as you actually need complexity your basic tools stop working. The "smug superiority" of the original post here is an admission that the author didn't need complex tools. The fact they recongized that, even if it was for the wrong reason if you're right about the smugness, is a good thing for their users.
      - robertoandred 4y ago
        So now that you've said React is indeed useful for complex projects, what relevance does the original post have here? It does nothing except clog up the comments with people tooting their own horns about how amazing they are for not using it.
- sneak 4y ago
rk06 4y ago
Vue, and svelte also exist?
- frodowtf 4y ago
  Does svelte still have this thing where you need to reassign a variable to itself for updating?
  - myrryr 4y ago
    Under very particular conditions, yes. fewer conditions now than it used to be, but you still need to do this at times. Usually I take it as a sign I should move to using a store. Sveltekit is very good.
  - sk0g 4y ago
    No? External changes to variables trigger reloads too, it was quite a nice experience coming from back end and hobby game dev. Now, the reactive blocks, where an update to _any_ variable used in them trigger the re-evaluation seemed rife for abuse - particularly when the variables could be brought in from other files, but I forget the mechanics behind that. I used it plenty of course. Forgot how it worked the day after I stopped working on the project though. For example, this file https://github.com/sk0g/peripheral-emulator-web-app/blob/master/src/lib/Ultrasonic2D.svelte https://github.com/sk0g/peripheral-emulator-web-app/blob/mas... Edit: unless you mean lines like `ultrasonicDetectedDistance.update(v => v = distance)`, which yeah was an interesting quirk. Not enough of a pain to go with something like React, thought that wouldn't meet the latency requirements for this project. TBF neither did Svelte entirely, but it got close.
sohex 4y ago
Take a look at htmx (https://htmx.org/ https://htmx.org/) if you haven't already. For my use cases, generally internal tooling like you mentioned, I've found it integrates extremely well with go templates and more often than not provides all the functionality that I'd generally be reaching to javascript for.
mirthflat83 4y ago
I knew it guys, I knew it. I knew a comment like this would be the most voted comment.
- DangitBobby 4y ago
  It's so tiresome. I hate Go but you don't see me bringing it up every time someone mentions it. For some reason it's irresistible, I guess because they know the choir will like the sermon.
  - selfmodruntime 4y ago
    You can actually measure the amount of dollars a language / framework / tools generates in real business applications by looking at how hated it is on HN. React generates billions of dollars every day.
- jiriknesl 4y ago
  It's the most upvoted comment for a reason. Back then, people fell in love with GMail and suddenly everyone thought they were building another GMail. This wasn't true. Most people were building an app with a couple of forms, a datagrid and maybe 2 highly interactive pages. PHP, Python & Ruby frameworks gave perfect support for all this >10 years ago. You had jQuery plugins you added to page in 30 minutes and you had validation. In 2 hours you had a datagrid. Autocomplete, datepicker, things like this was no problem. It was a form of egoism all the time. Coding Sign In page was work for less than an hour. Now, in React, it's 2 days. Look at developers now and compare them with senior devs a decade ago. My estimate is that development today is 4 times slower. Given a growth of salary at least 50%, a system back then in MySQL, jQuery, Django or Zend Framework for $40,000 is now $240,000 in React with GraphQL, Mongo, etc.
  - robertoandred 4y ago
    Do you think there aren't "plugins" for data grids, autocomplete, and date pickers for React?
papito 4y ago
I've been using ES6 directly, with ArrowJS for dynamic HTML and observable data, and it's been delightful.
orange8 4y ago
> I stopped guys, I stopped doing it. > Just simple go, html, css, and a bit of javascript when it's needed for a form. So you basically stopped being a fullstack dev, and moved to the back-end.
- vanviegen 4y ago
  And yet, they are making user-facing software... Magic!
  - orange8 4y ago
    It is not magic, it is back-end development. Calling it magic is like calling server-less architecture magic. Sit down and carefully consider what is the difference between front-end and back-end development, and why that distinction exists in the first place.
    - illiarian 4y ago
      What he is doing was literally called doing frontend until SPAs came along. PHP and RoR was frontend.
      - orange8 4y ago
        In your own words, please define what "front-end development" means to you when it comes to web development.
        illiarian 4y ago
        Anything that creates something directly user-facing on the web. With the rise of SPAs I've seen "traditional frontend" rebranded as "backend of the frontend" which is an awkward term to say the least.
        orange8 4y ago
        Okay. I'll explain it to you. It basically comes down to a server-client architecture. The server (db, server side code) is the backend, that the user never gets to see. The client (basically the browser - js, html and css) is what the user get's to see, not just through the interface, but by selecting "view source". So PHP and Rails are back-end languages. You never get to see the code and logic that generated the page because it is "at the back". Golang, which the poster mentioned, is also a back-end language. So if the core of your apps logic is at the back-end (server), what you are practicing is back-end dev. If the core is in the front (e.g. SPAs) then it's front-end dev. Sometimes the complexity can be split 50-50 between the back and front. But if your web-application just uses html, css and a sprinkling of JS, then it is back-end driven. Another category is a website, which does not really have any complexity whether at the back or front. So to correct your statement, PHP and RoR have never, at any point in time been considered front-end tech. If it is not html, css and js (including complile to js languages like ts), then it is not front-end dev.
zarzavat 4y ago
This is a bit like saying that you’ve stopped driving to work and now you only walk. That’s great for you if your home is close enough, then of course you should have been walking. But it’s not exactly generally applicable advice. The whole point of React is to create interactive UIs, that’s why it’s called “react”. And you can’t do that with a templating system.
- p5v 4y ago
  Just wait till you hear about HTMX: https://htmx.org/ https://htmx.org/
- MuffinFlavored 4y ago
  > No complicated build systems or web pack or dependency management system. I love statements like this. It's as if things are just complicated for the fun of it, not because they need to be/they solve complex problems.
  - kupopuffs 4y ago
    The complex problem of having great code turn compiled into shitty-ish code that some browsers support
  - irrational 4y ago
    I’m not sure the complex problems these tools were originally created for still exist. For example, do you really need to support old browsers? If not, you probably don’t need a transpiler anymore.
    - dimmke 4y ago
      Well, webpack has been replaced by vite (for those who pay attention to front-end trendfuckery) which is much simpler than Webpack and Babel is eliminated. We are still not quite at the point where it’s practical to not have a module bundler. Handling things like imports etc is still necessary. But we are moving away from React. Things are slowly going back to sanity. SvelteKit is an excellent step in this direction IMO.
joshmn 4y ago
Yes, this. 99% of us live in a world that does not need reactivity, yet so many of us are led to believe that we are in a world that does. All because Facebook made React (for what original use case? Facebook Ads Manager?) doesn't mean we're all going to be Facebook, need to be Facebook, or want to be Facebook. When I need the reactivity, I need to sprinkle it on; I don't need to use reactivity when it's not needed just for the few cases that do.
- zamnos 4y ago
  I mean, you're welcome to go back to PHP and jquery like it's the dark ages, but from where I'm coding, react is the only sane way to deal with a big complicated app.
  - xcrunner529 4y ago
    [dead]
  - irrational 4y ago
    How many apps are really big and complicated? I think that is OP’s point. 99% of sites and apps are not big and not really complicated.
  - damethos 4y ago
    Heh, this comment made me giggle. Indeed when someone says that React (or any other technology to write a SPA) sucks, they should just go back to PHP + jQuery in order to remember why we are here.
  - vanviegen 4y ago
    Going back to something like Ruby on Rails doesn't sound half bad...
    - aaronbrethorst 4y ago
      ssh, I love competing against people who think they have to build two codebases to ship one product.
midhhhthrow 4y ago
Yes! Thank heavens people are finally starting to see the light. All these nonsense “modern” frameworks with their broken layers of abstraction need to read that article by Joel spoelsky on leaky abstractions. And don’t be afraid to use this approach outside internal tools.
- bundie 4y ago
  Do you have a link to the article?
Existenceblinks 4y ago
> No react, no reduce, no apollo or graphql. No typescript, etc. All of these bring 10 benefit but add 12 problems back. It makes developing project slow at start, slow at medium term, and super garbage at long term. If developers get paid $100k+, I think they should be able to write good codes and have a good team instead of using these to save them from mediocrity. If you have to really do SPA, pick something that's not bloat, not slow, not flaw .. instead of "hiring pool" BS.
ta1243 4y ago
Absolutely. We have a mix of tools from the last 15 years, some perl, some php, some python. All trivial to work with. Some things need fancy react GUIs. Others need to surface business data to a small number of people in a simple and cost-effective way.
unxdfa 4y ago
Ironically I opened this up hoping to see the first comment was "just don't use React" and was even more surprised that it is exactly that and also what I've been doing for a while. I also wrote a < 0.5Kb DOM abstraction that basically just saves a bunch of typing (get element, replace element with something, go fetch some shit off the server, add style, remove style) and that covers about 90% of the "would be nice if it did this" use cases. This all gets compiled into one binary file, resources as well, chucked in a docker container and pushed to Kubernetes.
- muhehe 4y ago
  "They had us the first half, I'm not gonna lie"
justeleblanc 4y ago
You're using Go's build system, dependency management system, templating system (a transpiler...), etc. You're just replacing one "evil" by another "evil".
- smadge 4y ago
  The problem isn’t using tools at all, it’s using the wrong tool.
  - selfmodruntime 4y ago
    Modern react apps all use Vite, which is incredibly simple.
kahnclusions 4y ago
Great now you’ve tied yourself down to Go’s horror show…
sneak 4y ago
I, too, despise building SPAs. Forms were okay for 15 years and most of the time they are still okay.
hiccuphippo 4y ago
The early 2000 say hi, welcome back! Back then I needed nothing more than a simple $('container').html(response) to make a "SPA".
lakomen 4y ago
I've gone where you are too. To SPA and back again. The truth is solution is in the middle. Hotwire/Liveview type. This way you can have the performance and simplicity of Go with the reactivity of SPA and the SEO should you need it, I know, internal tools. The only package to my knowledge in Go doing this is "Kyoto" but it's far far away from being proper or in a easily usable state. If anyone knows any other Go packages that do hot/liveview please, I'm all ears.
gofreddygo 4y ago
Specifically for internal tools, this is a much efficient way. With anything more than html, css the complexity is not worth the return. We've done away with everything that needs internet to build or deploy (npm, dockerhub, brew, whatever). Primarily for the security theatre around package updates. So much simpler now. Backend is very well integrated with the entire ecosystem. Exact same setup as production. Folks who build internal admin tools tend to (and they should) know that part much better. Everything is instantaneous. We avoided all frontend libs. Some (like moment.js) needed extra work on the API side, but that took an hour at best to find an existing backend method to use. All of the admin UI stuff is like < 100 kb. In 1 repo. Everything works without javascript, in all browsers (including lynx). Night and day contrast against all previous versions where we used a mix of jquery, then angular and finally react with all their baggage and unexplainable dependencies to utter dismay. Clearly the case of using the wrong tools but good lord did it take a while to get rid of the FUD around html only tools.
1marc 4y ago
This is how most of the FrontendMasters.com website is made. Go/Hugo templates and vanilla JavaScript. People are always shocked at how fast our website is. Write the code necessary for the job at hand.

loeber 4y ago

Agreed. I like this blog post on the topic, from a startup moving from React to Vanilla JS and HTML: https://www.getwaitlist.com/blog/react-to-vanillajs https://www.getwaitlist.com/blog/react-to-vanillajs

lprd 4y ago

This is the way, and should honestly be the default unless you are 100% your software needs something like an SPA.

revskill 4y ago
That small "unless" might require a full rewrite your application.
- zelphirkalt 4y ago
  Well, it does require some though about SPA or website upfront, but will save lots of work and time to being online. I guess we can at least demand that much thought about things, instead of jumping immediately to SPA and causing weeks and months of more work. I have seen it. It is all "But React has this built in!" and "React does this nicely!" until it comes to actually implementing components. Without a need for interactive widgets to avoid page reloads and avoiding becoming a non-SPA again, it will take a lot more time to get things done with React, that it would take to simply churn out server-side rendered templates the traditional way. UIs that could have been done in 2 weeks the traditional way take suddenly multiple frontend devs a few months, with things like the back button not working correctly.
- jiriknesl 4y ago
  You could use the same argument for everything. Small "unless" and you are forced to make all your APIs generic because there might be many clients. Small "unless" and you'll ignore all power features of your database and dumb-down your approach to data because user might want to switch a database. Small "unless" and you will make your app ultrascalable even when you have no proof there'll ever be more than 100 users. This is a disease that makes development slower and more expensive even when 95% of time, the customer needed something fast and cheap. No, most devs aren't building another GMail, most devs are building something that could have been modelled in 2 weeks in Visual FoxPro 25 years ago.

realmod 4y ago

> a bit of javascript when it's needed for a form. Until you get told to implement more reactive features, then it's over. Using Pure JS/JQuery for reactiveness is outright horrible.

phendrenad2 4y ago
What do you mean by "reactiveness"?
- dhritzkiv 4y ago
  Updating the UI in response to user value input and state changes in real time: error messaging, validation, presenting more relevant additional inputs, formatting, etc.
  - cvdub 4y ago
    How much of a usability win is making things “real time?” Submitting a form and having the server do validation and render the error messages can feel just as fast. Plus, if you use the correct HTML input types the browser will handle the most obvious validation without any JS. You have to do validation on the server anyway. Why do it again on the front end?
    - wokwokwok 4y ago
      haha... Have you ever worked with a product manager? (: Sorry, those turn up as 'must have' features in like, meeting #2 with the product owner, because the UI feels old and rubbish without them. Technically? You're 100% right. ...but, I guarantee that even a LOB app, this will turn up, again and again and again as a feature request, until it becomes a tier 1 priority.
      - saurik 4y ago
        This clearly seems to read as a problem with the "product manager", not the technology.

phailhaus 4y ago

> Just simple go, html, css, and a bit of javascript when it's needed for a form I mean if your tools are that simple, this is a no-brainer. The problem is when you have to scale up. Internal tools can get complicated because their user base is often highly specialized technical users. Managing reusable components, behavior, and state of a complex application is when you need something like React.

danielheath 4y ago
Scale isn’t the problem, the product need for instant (client-side) reactivity is.
- tshaddox 4y ago
  I think the commenter is referring to the scale of functionality. Perhaps a better term would be scope.
  - danielheath 4y ago
    Right, but (eg) ERP tools have heaps of scope and very little need for client side reactivity.
- irrational 4y ago
  Instant? Most React sites I’ve visited feel anything but instant.
  - mrkeen 4y ago
    It's necessary but not sufficient

afavour 4y ago

I’ve grown to loathe React but your approach breaks down horribly once you start getting to a certain level of complexity. There is a reason frontend JS frameworks exist, I just wish the default wasn’t React.

dimmke 4y ago
It won’t be. React had its time and is now waning. The future is frameworks with no virtual DOM that are interoperable with other JS frameworks like Svelte.
deleted 4y ago
[deleted]
irrational 4y ago
Have you tried Vue? I work for a huge company (nearly 100,000 employees). We tested both React and Vue and settled on Vue. That was years ago, but we’ve had no regrets since.
- IshKebab 4y ago
  I've used Vue. It's much worse than React. It's probably ok for very small sites but its automatic reactivity system seems almost deliberately designed to produce spaghetti code and subtle bugs. Plus it has poor Typescript support. You don't have to worry at all about type errors in TSX. That said, I'm liking Yew a lot more than React. The difficult thing with React is state management, which is why it's common to resort to immutable state (even though that's a real pain in JS), and even then React chickens out by assuming components are impure by default. Everything makes way more sense in Rust. The big downside is that Yew doesn't really have anything like Bootstrap or Blueprint yet. I mean there are ports like Yewprint (great name) but they seem to be complicated to set up and you lose the really nice simplicity of Trunk.
  - Xevi 4y ago
    > Plus it has poor Typescript support. Vue 3 has excellent Typescript support. It's even built in Typescript. What exactly are you referring to when you say that it's "poor"?

jakelazaroff 4y ago

Why not use something like Retool? IMO if you’re building internal tools from scratch like that there’s a 99% chance you’re spending too much time on them.

interlocutor 4y ago
Or Airforms if you don't like coding: https://airforms.com/ https://airforms.com/

paulddraper 4y ago

That works until you need something crazy like a searchable drop-down.

cvdub 4y ago
Is that sarcasm? It’s not hard to implement a searchable dropdown in vanilla JS.
dham 4y ago
select boxes are searchable by default. Just isn't obvious. You can also use a datalist
onion2k 4y ago
This is where a good understanding of HTML helps - you can use a fatalist instead of a select. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...
- squeaky-clean 4y ago
  On mobile (safari) it doesn't show results as you type. You have to type your partial string and then press the dropdown selector to see the list filtered by your string.
- robertoandred 4y ago
  And datalists are incredibly limited in functionality and styling.
  - onion2k 4y ago
    Sure, so if you need more functionality or different styling they won't work. But I suspect many devs reach for a JS searchable dropdown replacement without even bothering to ask the question of whether they really need something else.

waboremo 4y ago

Makes sense, you were creating static pages but were using a tool that is dramatically overengineered for that use case. I would've switched to Astro for that use case, mainly because you could still leverage your understanding of React/Vue/Svelte/whatever within those mostly static pages very easily, plus the markdown support is brilliant for internal tooling.

robertoandred 4y ago

I’ve never understood this bizarre superiority complex people develop for themselves because they use basic tools for basic projects.

onion2k 4y ago
Removing complexity where you can is a good thing. Being able to recognize when you don't need a complex system is a skill. Many devs fall into the "One tool for every problem" trap by defaulting to the same boilerplate project for everything (eg create-React-app or Next.JS) and end up making something complex when a much simpler system would have worked better. If you have a basic project the tools should be basic.
- robertoandred 4y ago
  And if you don't have a basic project, why should you stick with basic tools just to enforce some smug sense of superiority?
  - onion2k 4y ago
    Your tools should be as complex as they need to be. For most apps, that is a lot simpler than the developer has made them. The inverse isn't true because as soon as you actually need complexity your basic tools stop working. The "smug superiority" of the original post here is an admission that the author didn't need complex tools. The fact they recongized that, even if it was for the wrong reason if you're right about the smugness, is a good thing for their users.
    - robertoandred 4y ago
      So now that you've said React is indeed useful for complex projects, what relevance does the original post have here? It does nothing except clog up the comments with people tooting their own horns about how amazing they are for not using it.
sneak 4y ago

rk06 4y ago

Vue, and svelte also exist?

frodowtf 4y ago
Does svelte still have this thing where you need to reassign a variable to itself for updating?
- myrryr 4y ago
  Under very particular conditions, yes. fewer conditions now than it used to be, but you still need to do this at times. Usually I take it as a sign I should move to using a store. Sveltekit is very good.
- sk0g 4y ago
  No? External changes to variables trigger reloads too, it was quite a nice experience coming from back end and hobby game dev. Now, the reactive blocks, where an update to _any_ variable used in them trigger the re-evaluation seemed rife for abuse - particularly when the variables could be brought in from other files, but I forget the mechanics behind that. I used it plenty of course. Forgot how it worked the day after I stopped working on the project though. For example, this file https://github.com/sk0g/peripheral-emulator-web-app/blob/master/src/lib/Ultrasonic2D.svelte https://github.com/sk0g/peripheral-emulator-web-app/blob/mas... Edit: unless you mean lines like `ultrasonicDetectedDistance.update(v => v = distance)`, which yeah was an interesting quirk. Not enough of a pain to go with something like React, thought that wouldn't meet the latency requirements for this project. TBF neither did Svelte entirely, but it got close.

sohex 4y ago

Take a look at htmx (https://htmx.org/ https://htmx.org/) if you haven't already. For my use cases, generally internal tooling like you mentioned, I've found it integrates extremely well with go templates and more often than not provides all the functionality that I'd generally be reaching to javascript for.

mirthflat83 4y ago

I knew it guys, I knew it. I knew a comment like this would be the most voted comment.

DangitBobby 4y ago
It's so tiresome. I hate Go but you don't see me bringing it up every time someone mentions it. For some reason it's irresistible, I guess because they know the choir will like the sermon.
- selfmodruntime 4y ago
  You can actually measure the amount of dollars a language / framework / tools generates in real business applications by looking at how hated it is on HN. React generates billions of dollars every day.
jiriknesl 4y ago
It's the most upvoted comment for a reason. Back then, people fell in love with GMail and suddenly everyone thought they were building another GMail. This wasn't true. Most people were building an app with a couple of forms, a datagrid and maybe 2 highly interactive pages. PHP, Python & Ruby frameworks gave perfect support for all this >10 years ago. You had jQuery plugins you added to page in 30 minutes and you had validation. In 2 hours you had a datagrid. Autocomplete, datepicker, things like this was no problem. It was a form of egoism all the time. Coding Sign In page was work for less than an hour. Now, in React, it's 2 days. Look at developers now and compare them with senior devs a decade ago. My estimate is that development today is 4 times slower. Given a growth of salary at least 50%, a system back then in MySQL, jQuery, Django or Zend Framework for $40,000 is now $240,000 in React with GraphQL, Mongo, etc.
- robertoandred 4y ago
  Do you think there aren't "plugins" for data grids, autocomplete, and date pickers for React?

papito 4y ago

I've been using ES6 directly, with ArrowJS for dynamic HTML and observable data, and it's been delightful.

orange8 4y ago

> I stopped guys, I stopped doing it. > Just simple go, html, css, and a bit of javascript when it's needed for a form. So you basically stopped being a fullstack dev, and moved to the back-end.

vanviegen 4y ago
And yet, they are making user-facing software... Magic!
- orange8 4y ago
  It is not magic, it is back-end development. Calling it magic is like calling server-less architecture magic. Sit down and carefully consider what is the difference between front-end and back-end development, and why that distinction exists in the first place.
  - illiarian 4y ago
    What he is doing was literally called doing frontend until SPAs came along. PHP and RoR was frontend.
    - orange8 4y ago
      In your own words, please define what "front-end development" means to you when it comes to web development.
      - illiarian 4y ago
        Anything that creates something directly user-facing on the web. With the rise of SPAs I've seen "traditional frontend" rebranded as "backend of the frontend" which is an awkward term to say the least.
        orange8 4y ago
        Okay. I'll explain it to you. It basically comes down to a server-client architecture. The server (db, server side code) is the backend, that the user never gets to see. The client (basically the browser - js, html and css) is what the user get's to see, not just through the interface, but by selecting "view source". So PHP and Rails are back-end languages. You never get to see the code and logic that generated the page because it is "at the back". Golang, which the poster mentioned, is also a back-end language. So if the core of your apps logic is at the back-end (server), what you are practicing is back-end dev. If the core is in the front (e.g. SPAs) then it's front-end dev. Sometimes the complexity can be split 50-50 between the back and front. But if your web-application just uses html, css and a sprinkling of JS, then it is back-end driven. Another category is a website, which does not really have any complexity whether at the back or front. So to correct your statement, PHP and RoR have never, at any point in time been considered front-end tech. If it is not html, css and js (including complile to js languages like ts), then it is not front-end dev.

zarzavat 4y ago

This is a bit like saying that you’ve stopped driving to work and now you only walk. That’s great for you if your home is close enough, then of course you should have been walking. But it’s not exactly generally applicable advice. The whole point of React is to create interactive UIs, that’s why it’s called “react”. And you can’t do that with a templating system.

p5v 4y ago
Just wait till you hear about HTMX: https://htmx.org/ https://htmx.org/
MuffinFlavored 4y ago
> No complicated build systems or web pack or dependency management system. I love statements like this. It's as if things are just complicated for the fun of it, not because they need to be/they solve complex problems.
- kupopuffs 4y ago
  The complex problem of having great code turn compiled into shitty-ish code that some browsers support
- irrational 4y ago
  I’m not sure the complex problems these tools were originally created for still exist. For example, do you really need to support old browsers? If not, you probably don’t need a transpiler anymore.
  - dimmke 4y ago
    Well, webpack has been replaced by vite (for those who pay attention to front-end trendfuckery) which is much simpler than Webpack and Babel is eliminated. We are still not quite at the point where it’s practical to not have a module bundler. Handling things like imports etc is still necessary. But we are moving away from React. Things are slowly going back to sanity. SvelteKit is an excellent step in this direction IMO.

joshmn 4y ago

Yes, this. 99% of us live in a world that does not need reactivity, yet so many of us are led to believe that we are in a world that does. All because Facebook made React (for what original use case? Facebook Ads Manager?) doesn't mean we're all going to be Facebook, need to be Facebook, or want to be Facebook. When I need the reactivity, I need to sprinkle it on; I don't need to use reactivity when it's not needed just for the few cases that do.

zamnos 4y ago
I mean, you're welcome to go back to PHP and jquery like it's the dark ages, but from where I'm coding, react is the only sane way to deal with a big complicated app.
- xcrunner529 4y ago
  [dead]
- irrational 4y ago
  How many apps are really big and complicated? I think that is OP’s point. 99% of sites and apps are not big and not really complicated.
- damethos 4y ago
  Heh, this comment made me giggle. Indeed when someone says that React (or any other technology to write a SPA) sucks, they should just go back to PHP + jQuery in order to remember why we are here.
- vanviegen 4y ago
  Going back to something like Ruby on Rails doesn't sound half bad...
  - aaronbrethorst 4y ago
    ssh, I love competing against people who think they have to build two codebases to ship one product.

midhhhthrow 4y ago

Yes! Thank heavens people are finally starting to see the light. All these nonsense “modern” frameworks with their broken layers of abstraction need to read that article by Joel spoelsky on leaky abstractions. And don’t be afraid to use this approach outside internal tools.

bundie 4y ago
Do you have a link to the article?

Existenceblinks 4y ago

> No react, no reduce, no apollo or graphql. No typescript, etc. All of these bring 10 benefit but add 12 problems back. It makes developing project slow at start, slow at medium term, and super garbage at long term. If developers get paid $100k+, I think they should be able to write good codes and have a good team instead of using these to save them from mediocrity. If you have to really do SPA, pick something that's not bloat, not slow, not flaw .. instead of "hiring pool" BS.

ta1243 4y ago

Absolutely. We have a mix of tools from the last 15 years, some perl, some php, some python. All trivial to work with. Some things need fancy react GUIs. Others need to surface business data to a small number of people in a simple and cost-effective way.

unxdfa 4y ago

Ironically I opened this up hoping to see the first comment was "just don't use React" and was even more surprised that it is exactly that and also what I've been doing for a while. I also wrote a < 0.5Kb DOM abstraction that basically just saves a bunch of typing (get element, replace element with something, go fetch some shit off the server, add style, remove style) and that covers about 90% of the "would be nice if it did this" use cases. This all gets compiled into one binary file, resources as well, chucked in a docker container and pushed to Kubernetes.

muhehe 4y ago
"They had us the first half, I'm not gonna lie"

justeleblanc 4y ago

You're using Go's build system, dependency management system, templating system (a transpiler...), etc. You're just replacing one "evil" by another "evil".

smadge 4y ago
The problem isn’t using tools at all, it’s using the wrong tool.
- selfmodruntime 4y ago
  Modern react apps all use Vite, which is incredibly simple.

kahnclusions 4y ago

Great now you’ve tied yourself down to Go’s horror show…

sneak 4y ago

I, too, despise building SPAs. Forms were okay for 15 years and most of the time they are still okay.

hiccuphippo 4y ago

The early 2000 say hi, welcome back! Back then I needed nothing more than a simple $('container').html(response) to make a "SPA".

lakomen 4y ago

I've gone where you are too. To SPA and back again. The truth is solution is in the middle. Hotwire/Liveview type. This way you can have the performance and simplicity of Go with the reactivity of SPA and the SEO should you need it, I know, internal tools. The only package to my knowledge in Go doing this is "Kyoto" but it's far far away from being proper or in a easily usable state. If anyone knows any other Go packages that do hot/liveview please, I'm all ears.

gofreddygo 4y ago

Specifically for internal tools, this is a much efficient way. With anything more than html, css the complexity is not worth the return. We've done away with everything that needs internet to build or deploy (npm, dockerhub, brew, whatever). Primarily for the security theatre around package updates. So much simpler now. Backend is very well integrated with the entire ecosystem. Exact same setup as production. Folks who build internal admin tools tend to (and they should) know that part much better. Everything is instantaneous. We avoided all frontend libs. Some (like moment.js) needed extra work on the API side, but that took an hour at best to find an existing backend method to use. All of the admin UI stuff is like < 100 kb. In 1 repo. Everything works without javascript, in all browsers (including lynx). Night and day contrast against all previous versions where we used a mix of jquery, then angular and finally react with all their baggage and unexplainable dependencies to utter dismay. Clearly the case of using the wrong tools but good lord did it take a while to get rid of the FUD around html only tools.

1marc 4y ago

This is how most of the FrontendMasters.com website is made. Go/Hugo templates and vanilla JavaScript. People are always shocked at how fast our website is. Write the code necessary for the job at hand.