101–110 of 297 posts
Except the most employable technology keeps changing every few years. TypeScript and Go and Rust are the hot ones now and they were barely on the radar a year ago. Ofc I am inserting them into work projects as I need to learn them.
Rust may be “hot” but there are far more Java jobs than Rust jobs and I highly doubt that’s going to change anytime soon. And indeed Java developers have been highly employed for quite some time.
Earlier quoted context omitted.
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 r…
Certainly not a showstopper though, passing a URI is easy enough!
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…
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…
You can use something like https://github.com/vriad/zod to get both runtime validation and static types (via inference) at the same time. The downside is defining your types in a DSL instead of plain TS, but I think it's worth it for the runtime validation.
It probably depends on your project, but I find type checking to be at least as crucial on the backend as the frontend (probably moreso), and being able to share types/have editor auto-complete across the whole stack is a godsend. While node isn't my favorite backend environment, it's not too bad (async/await are fantastic for io), and code sharing/type sharing makes it the most productive choice overall imho, all things considered.
Clojure's a lot of fun though, and it has taught me a lot, so I do see where you're coming from!
Except the most employable technology keeps changing every few years. TypeScript and Go and Rust are the hot ones now and they were barely on the radar a year ago. Ofc I am inserting them into work projects as I need to learn them.
Listed as "boring":
- Postgres 1986
- Python 1989
- MySQL 1995
- PHP 1995
Relatively "hot":
- Go 2007
- Rust 2010
- TypeScript 2012
- GraphQL 2012
- React 2013
SPAs (single page applications) aren't boring yet. we really don't know how to do this well, as a community, and the cambrian explosion of JavaScript tech is almost all around trying to make this extremely un-boring application style more boring. The SPA is a gateway drug to spending lots and lots of innovation tokens, more, really, than almost any dev team can afford. For example, I would consider each of Webpack, P…
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…
There's certainly answers which seem promising for all of those areas, but it seems to me that in every React project I work in, "use React" is the easy part - it's the 50 other decisions that need to be made as a consequence of that first easy decision that waste a lot of time and energy.
Looking back, the best technical decisions were:
- using an SQL database with lots of constraints and foreign keys and indexes. It's like typing for data.
- emphasis on shell scripts and leaning on UNIX features (since these continue working in ten years rather than being abandoned)
- deleting as many libraries and dependencies as practical (over a ten-year time frame, 80% will disappear or change in ways that require huge mental RAM on your behalf)
- a preference for paying for hardware to solve performance issues (vs. complicating the code with fancy solutions)
For anyone interested, I go into more detail in this video https://www.youtube.com/watch?v=rQegYUsU7ec
We learned this lesson the hard way. A few years back, for a start-up, we picked angular 2.0 as our choice for frontend stack, when it is released. Though it was fun to develop it, We faced a lot of unknowns and issues to finally ship it. Too many changes for each version, The bundle size was too big. Angular SPAs were not great for SEOs etc. We ended up missing the shipping deadline by a couple of months. When you r…
"I'm not interested in learning Go because it doesn't have many compelling features"
"That IS the feature"
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…
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…
The non existent standard library and pretty nutty dependency management makes JS a bad choice for back-ends. There was a article a few days ago on how Deno is aiming to fix most of this and other issues, but I wouldn't use it for a couple years.
Back ends tend to stick around far long than front ends. Every company I've worked at is still running their original back ends, some decades old. Front ends are easier to replace because it tends to be just UI stuff, not a lot of business logic. I apt to take a lot less risk on the backend. It's probably going to be around forever and customers don't have to see how crusty it is :)
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 was an early Python adopter (1995/1996) and could not for the life of me find anybody who would consider letting me use it in 'mainstream' commercial software projects. Then all the sudden about 10 years ago it exploded in popularity big time.
But I'd moved on to working on other things by then, I no longer enjoy writing in Python.
Wow, this sounds like the classic "I was into that band before they popular" indie snob, hah!