Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Choose Boring Technology (2015)

mcfunley.com

Post reply on HN
Print view View original

91–100 of 297 posts

Re: Choose Boring Technology (2015)

#91

Post by TheDong »

kitd wrote: post #76
nine_k wrote: post #62

I still think that "boring" is a wrong word. Choose the technology you know in and out, and are immediately productive with. Choose the technology which is sure to be around in 5-7 years, preferably 10-15. Choose the technology for which you are comfortable hiring the next 15 engineers. This does not mean that you need to choose something unpleasant, unergonomic, or ancient. Neither does it mean that you need to choo…

> YouTube was (and still largely is) written in Python, way before it was cool and well-known. I agree with you on just about everything, but python was well-known well before YT. Django was a staple of the early web.

The staples of the early web, in my mind, are html and perl CGI scripts. php might make the cut as early web, but web frameworks, like those in ruby and python, feel to me me much less like the early web, and much more like the web 2.0 days.

Re: Choose Boring Technology (2015)

#92

Post by peferron »

Also: please, please pay attention to the fundamental design decisions that underpin the technology you're choosing!

Set aside the GitHub stars, contribution graphs and HN reviews, and boil the tech down to its fundamental principles. Then ask yourself how a perfect implementation of that design would solve your problems. It it solves them well, you're golden as long as the project is reasonably healthy. If it doesn't solve them well, you might be setting yourself up for serious pain down the line, and need to make a very conscious choice about whether the short-term benefits of that technology choice are worth it, and how an eventual migration to a better-fitting design would look like.

Re: Choose Boring Technology (2015)

#93

Post by sradman »

choeger wrote: post #51
gavinray wrote: post #23

Earlier quoted context omitted.

I don't know that necessarily correct. Previous startup I was at had a stack like this: - Frontend: Vue + Typescript - Android/iOS App: Vue (NativeScript/Capacitor) + Typescript - Backend: Node + Typescript - Database: Postgres - Deployment: Everything in Docker containers I know of a lot of places taking similar stances where the frontend and mobile apps are done in this way (IE React and React Native) and then you…

You basically have arrived where lisp was some decades ago. Logical next steps are to write the OS and the editor and the VCS in JavaScript. However, at some point you will have a look into your myriad of nodejs dependencies and see with horror that they rely on C++ extensions. Then you learn that your precious stack is just a GCC upgrade away from not building anymore. And noone in your company even remembers what t…

Choose “proven” technology, or “boring” tech as the original article calls it, applies here too. Popular libraries that are embedded in multiple language runtimes are written in C. SQLite comes to mind. Choose boring dependencies written with boring integration interfaces.

Re: Choose Boring Technology (2015)

#94

Post by lugged »

gcoguiec wrote: post #83
nine_k wrote: post #62

I still think that "boring" is a wrong word. Choose the technology you know in and out, and are immediately productive with. Choose the technology which is sure to be around in 5-7 years, preferably 10-15. Choose the technology for which you are comfortable hiring the next 15 engineers. This does not mean that you need to choose something unpleasant, unergonomic, or ancient. Neither does it mean that you need to choo…

Mature Technology? ( https://en.wikipedia.org/wiki/Mature_technology )

Ya'll seem to think "Choose Mature Technology" would result in the same amount of discussion and upvotes on hacker news.

Re: Choose Boring Technology (2015)

#95

Post by peferron »

rdgthree wrote: post #90
peferron wrote: post #80

Earlier quoted context omitted.

I just built a frontend and backend with TS following this same logic. I'm super happy with TS for the frontend, but I regret picking it for the backend and am considering rewriting the backend in Clojure while it's still early. My reasons are: - I don't need to share type definitions between the frontend and backend; the frontend can generate TS type defs using GraphQL introspection regardless of which language the…

It'll depend on what you're building, but there's some value in rendering React on our backend. For example, we render documents (HTML => PDF) and emails with the same React components we use for our frontend to keep styling consistent. There are also some utils we use (in similar contexts) on both sides largely for things like string formatting or annoying math. Not a ton of stuff, but it's nice to have one bulletpr…

I wasn't very clear with my earlier description; the frontend is a SPA served by Node.js, while the backend is a completely separate GraphQL API service which I'm considering to rewrite in Clojure.

So the frontend can actually do SSR to render PDFs or emails. However, it would definitely be much harder to to ensure that any phone formatting or fee calculation done directly in the user's browser matches what the API returns. So yeah, definite benefits in sharing a language there. Thanks for the examples!

Re: Choose Boring Technology (2015)

#96

Post by dgb23 »

JamesBarney wrote: post #87
baron816 wrote: post #38

Earlier quoted context omitted.

React has been around for 7 years. ES2015 has been around for 5 years. React has become the de facto lingua franca for front end development. Could you imagine some CTO or technical lead saying, "We're not going to use React because it's too new and unproven." React has proven itself. Facebooks has 100K+ components. There are no unknowns there. Using jQuery or vanilla JS instead would be way more problematic and have…

Despite React being around for 7 years, it still seems slower to develop, slower in performance, and buggier than an equivalent SSR app. Despite having a couple years more experience in React than SSRs, I can knock out a 10 page web app with an SSR framework from scratch in a day (security, frontend, backend, data schema, deployment) but it takes me a couple more to knock out the same app in React. (Crud/Search/Repor…

It depends on the project. I’m way, way more productive with a React frontend environment (webpack, babel, tailwind, next) when working with handcrafted designs. Even when the interactivity is trivial. And I know from experience that interactivity inevitably becomes more involved very often.

One key feature is that JSX works on both the frontend and the backend.

Re: Choose Boring Technology (2015)

#97

Post by ashildr »

kitd wrote: post #76
nine_k wrote: post #62

I still think that "boring" is a wrong word. Choose the technology you know in and out, and are immediately productive with. Choose the technology which is sure to be around in 5-7 years, preferably 10-15. Choose the technology for which you are comfortable hiring the next 15 engineers. This does not mean that you need to choose something unpleasant, unergonomic, or ancient. Neither does it mean that you need to choo…

> YouTube was (and still largely is) written in Python, way before it was cool and well-known. I agree with you on just about everything, but python was well-known well before YT. Django was a staple of the early web.

I feel old now, for me the early web was on Mosaic, shortly after I discovered gopher at uni.

But seriously, the dynamically generated content of the early web was cgi, perl, later some python (as in scripts, not in django)

Re: Choose Boring Technology (2015)

#98

Post by jmchuster »

kitd wrote: post #76
nine_k wrote: post #62

I still think that "boring" is a wrong word. Choose the technology you know in and out, and are immediately productive with. Choose the technology which is sure to be around in 5-7 years, preferably 10-15. Choose the technology for which you are comfortable hiring the next 15 engineers. This does not mean that you need to choose something unpleasant, unergonomic, or ancient. Neither does it mean that you need to choo…

> YouTube was (and still largely is) written in Python, way before it was cool and well-known. I agree with you on just about everything, but python was well-known well before YT. Django was a staple of the early web.

Django released July 15, 2005

YouTube founded February 14, 2005

Re: Choose Boring Technology (2015)

#99

Post by ashildr »

l0b0 wrote: post #13

As relevant as ever. It's fascinating how big web stacks are these days, even for small-to-medium sites: various combinations of at least one styling language (SASS/LESS/CSS), frontend framework (Angular/React), frontend language (JavaScript/TypeScript/Node.js), backend framework (Django/Express/Spring/Rails) backend language (Python/Ruby/PHP/Perl/Java), and message bus (ZeroMQ/Redis/RabbitMQ). That's just the fronte…

The young people in my company made sure our webpage is a react app.

I gave in because they are having fun and it looks good, but it could have been done in static html (maybe using a generator) way more easily.

It hurts me everytime I‘m thinking about it.

Re: Choose Boring Technology (2015)

#100

Post by arcturus17 »

JamesBarney wrote: post #87
baron816 wrote: post #38

Earlier quoted context omitted.

React has been around for 7 years. ES2015 has been around for 5 years. React has become the de facto lingua franca for front end development. Could you imagine some CTO or technical lead saying, "We're not going to use React because it's too new and unproven." React has proven itself. Facebooks has 100K+ components. There are no unknowns there. Using jQuery or vanilla JS instead would be way more problematic and have…

Despite React being around for 7 years, it still seems slower to develop, slower in performance, and buggier than an equivalent SSR app. Despite having a couple years more experience in React than SSRs, I can knock out a 10 page web app with an SSR framework from scratch in a day (security, frontend, backend, data schema, deployment) but it takes me a couple more to knock out the same app in React. (Crud/Search/Repor…

I’m in the same boat, SPA feels slower to develop than SSR to me, despite being fairly more experienced in SPA.

However, I find it hard to justify choosing SSR for new projects anymore because:

- React makes certain basic things (eg, fetching data, auth) more complex than in SSR, but the overall experience is weirdly addictive and exhilarating at times, especially component reusability on a well set up project.

- My clients love it. I am 100% in the camp of “users don’t give a shit how the sausage is made”, but I constantly get praise on how “smooth” the UX feels. I know there are SSR technologies (eg Turbolinks) that can emulate this, but at this point I’m having a hard time justifying learning them properly and risking missing out on that maybe superficial, but addictive, customer praise.

- It is indeed what I know best, so what the hell...

I believe a competent web developer should know both SPA and SSR and apply what best fits the requirements at hand, but I can also appreciate why devs form biases one way or the other and how this has become a hotly contested topic, and I think we may still be in the same spot in three to five years.

Post reply on HN