Hacker News Reader

Comment by whalesalad | Hacker News Reader

Technology is usually just a means to an end. Unless IP is what you are selling, boring is great. I’ve seen SO many teams burn SO much energy on complicated stacks just to drink kool-aid. It’s mind bogglingly frustrating, especially as a contractor. At the end of the day it’s great for me: I get brought into shit shows to clean up the mess. But deep down, I want projects to succeed and clean/sound systems architecture is how you do that. Doesn’t matter if it’s PHP, Python or Java.

It hurts to see people continue to make mistakes over and over, so I’m working on a new website and series of engineering posts to help share my approach to a lot of these problems.

Any product I start building usually begins in Rails. React is great. Vue is great. It’s not necessary, good ol’ request/response is just fine. You don’t need a service mesh. You don’t need Kafka. You add that stuff later when it’s required... if it’s required. Rails can’t be beat for startups. I wouldn’t waste any time on a single page app, it’s a completely pointless endeavor unless you have proven traction, users, revenue etc... and can afford to do it correctly.

View on HN

Yes! So much this. Every startup I've worked with regretted choosing a trendy tech stack early on. Speed of development is BY FAR the most important thing and the SPA/Javascript framework de jour trend of the past few years is an antithetical to rapid iteration. As a consultant, I'll happily bill hours to untangle that mess, but it's very frustrating to see startups with lots of potential spinning their wheels with unnecessary bloat on the front end.

Totally disagree re. SPA frameworks. Having mastered one of the popular ones, I've found I can now turn out fairly complex apps that I never could have contemplated building solo a few years ago.

Completely agree. My default stack is now react + an api in the backend. The way you can reuse components is a great time saver (even for simple apps). I also like redux-thunk to separate all my API calls from the components. Makes everything very lean and readable.

I feel way more productive today than in the old jQuery, knockout messes

Same here! What's your choice of stack for the api?

PS - I need to build an api for an app with a React front-end. My choice of language is Python (because I'm super familiar and because of the great ORMs Python has).

Django-rest-framework is super productive once you learn it. It has a bit of a learning curve, but it’s worth it if you are writing a lot of APIs, especially if you’re doing a lot of CRUD.

It’s my go to tool when I need to get stuff done. Combined with react and typescript, developing full stack is really smooth.

I've started to use TypeScript and React on the front end, with a JSON RPC middleware on an express server with helpers that automatically implement service interfaces for API calls, action creators and reducer handlers. And all of them are type-safe.

I've spent a lot of time building CRUD APIs and GraphQL interfaces, and this is the simplest solution that has saved me so much development time. JSON RPC gets so much hate, but it's made my life so much simpler.

Sounds neat, what project are you working on?

I'm currently working on various projects at work that I cannot discuss here, but in parallel I've been working on an express / TypeORM / React (SPA & SSR) framework that I hope to release one day as an open source project.

The main focus is to:

- easily share React components that use Redux state and actions between projects

- rapidly develop new server-side services and immediately use them in React components (by removing code duplication when it comes to creating action creators and action types)

- have type safety

- provide basic server-side and client-side components for basic user actions such as login, user profile, etc

- make it easy to write tests

And at some point in the future, I hope to make it generic enough so the libraries mentioned above can be swapped for other libraries, but that might be too much work :)

Sounds like a lot of work, how do you know that it is a net time saver?

Haha, I guess it is not at the moment, but it keeps me amused. In the first post I was just referring to using JSONRPC over standard REST endpoints as the time saver.

thats probably due to having more expirience, but you still have to do the crud yourself and all the other things that you otherwise would get for free.

i like next.js now but for simplicity's sake i think parrent is right.

For my past six or seven contracts I've been carrying around the same set of fetch util functions I wrote in ES6 a few years ago - it's less than 200 lines of code. If the API endpoints are ready to go, CRUD is the easy part. Which tools would you consider CRUD as something you get free?

It's a bigger investment I would say, but once you build a very well defined api structure and frontend components, things start getting very fast to develop. Also you get the added benefit of completely separate front and backend logic which is very useful in a multi developer environment.

And then 3 years later after you moved on someone like me has to come along and cleanup the project.

The current project I work on is angular1 based witch is outdated and it also sucks if the dev was just learning it at the time, the backend is done with a PHP framework that is today outdated/deprecated, this is not an old project(probably started when angular was the hot new thing)

I am sure your react project in 5 years if you will try to build it from scratch you will find issues with the npm dependencies, lots of deprecation warnings in your modules in react. I am all for the best tool for the job , use SPAs where it makes sense,

how is that any different from a custom rails server with dozens of gems that need to be upgraded. how do you build a site without any of these risks and make it last for a decade or more?

By choosing a language with a large standard library and then relying on that library rather than on frameworks of the day as much as possible.

For example, many vanilla PHP applications written 10 years ago will still run just fine today, whereas upgrading from one version of Laravel to the next version can be a major trauma.

From what I remember of php applications written around 2009, a lot of them had SQL injection and bizarre roll-your-own-security vulnerabilities. There were some pretty appalling things like the same (wrong) CSRF token validation code being copy-pasted into fifty different files, or passwords saved in plaintext, or customer credit card info sent over email, or every single site being mashed into joomla and drupal no matter whether it actually fit and then never updated.

These are all examples of pretty amateur mistakes. This reads more like an argument for keeping senior devs on the payroll than a warning about not using a framework.

It can be both. Senior devs and frameworks are two complimentary ways of managing chaos and organising your code.

A framework will not prevent things to become a mess, in the angular project I inherited in most places the rootScope is injected everywhere, I do not blame the developers either, the angular architecture is not great and when you have a lopt of new tasks for you to implement you don't always have the time to reimplement things, but sometimes the correct solution is not used , though you may want to claim that your favorite framework makes it harder to do the wrong thing.

Yes. I'm working with garbage legacy drupal stuff right now. It is so bad. Makes me die a little every day.

There are a large number of non-professionals and beginners coding in PHP, they start from say an existing WP plugin ,open it in notepad and start editing until it works,

it happens in JS land too, find some js package made by a newb and run a linter on it, I see issues on code that is written by coders with a few years of experience where they do not use properly the array functions, do not use correctly the lamda, they copy paste same code in 3 or more places.

Do you think that all js,Ruby or Pthon dev would properly use SQL without an ORM? I dpn;t think so, I found recently bugs in a JS codebase where file upload would fail if the file had non US characters in it's name because some parameter was not url encoded, so all developers make mistakes and ORMs were not popular at that time to prevent this kind of mistakes for SQL.

and yet, a lot of vanilla PHP is a mess of code whereas when i had to work on a laravel application i found it a pleasure to work with (even without having any prior PHP experience)

pick your poison i guess.

I agree with you, but what sucks is that instead of 1 or 2 frameworks that are stable you get a large number of them that get deprecated, I was brought to work into 2 PHP projects, one was using yii1 and the second Silex , both frameworks were deprecated and some of the dependencies are deprecated too. I did not worked on Laravel, I hope when I will it won't be again on an unsupported old version.

Also it sucks when you search for help and you need to double check if the solution is for yii1 not 2, or angular1 not the others etc.

that is very true. at least angular1 was stable for quite some time i'd say, it was quite usable until they started working on angular 2.

that means when selecting a framework, don't pick the newest, but look for something that promises stability, and then stick with it. i picked aurelia to once angular 1 was no longer usable. and although i mainly chose it for other reasons, it looks like it will be a stable choice.

It could be a good stable framework, though can you put yourself in my place, say in 5 years you are called to work on your current project, some new small feature must be added or some bug needs to be fixed. So I will have to learn to work with yet another old framework that is no longer populkar and the developers that wrote the code moved to the next cool thing.

It is what it is, I will have to learn and maintain others code like I always done but it would be better if we had some stability as I mentioned, some standard web framework built in JS and browsers that most developers would use and the devs that want new and shiny could ignore that and use whatever.

well, one of the key things of aurelia is to use standards as much as possible. so as javascript evolves aurelia will pick up on these things and remove any homegrown things to use whatever javascript provides instead. so it is up to javascript to grow a decent standard library.

As the other mentioned there are other devlopment stasks that are stable, to give more examples but not for Web, you can get ther code for an old .Net,Java,Qt application, download the SDK used for that version and just build it. There are not 100+ things you need, the SDK contains the compilers, a huge standard library other build tools. If the project had other dependencies those are some standalone .dll or .jar files that you place in the application folder.

For web when I inherit an older project I need to spend a lot of time in finding the correct version of things, like for an older react project it was using an official jsx transpiler but today that package is deprecated you can't just npm install it, so I would have been forced to upgrade the entire build system to use the new thing , but at that moment I had to fix a small thing so I found a hack for the issue and postpone the fixing of that issue.

What I think Web needs is some standard framework, or a framework core maybe jsx or other template thing but something standard to be used in mst projects and for side projects we can toy with the shiny new frameworks and languages.

ok, so essentially the problem is the fragmented development and feature libraries. that is a fair point. let's hope that some javascript frameworks develop into that direction.

Try Vanilla.js.

It is missing a lot of stuff, like I want a modal popup, I need to search the web for a solution,

I want a DataGrid with sortable and re sizable columns, i need to search the web, find something that is compatible and also make sure the license is compatible

I want a basic Dropdown widget that can do basic things like ex have a flag+country name or have a list of fonts where each font is using it's family to be rendered. Also the scrollbars can't be themed for when elements overflow in all browsers so you are forced to find something that reimplements the scrollbars.

When I give example of Qt,Net or Java I include the full SDK , if you did not worked with this kind of SDKs maybe you worked with Android one, basically you have the language STL plus anything you need from file I/O, Networking, Widgets, to the serial ports,screen, and a lot of things, you don't have to package install a new thing for each feature.

Sure it is not perfect, but it is still a lot better than any framework as a long-term viable foundation.

All the stuff you mention can be solved with simple libraries, maybe you could push for a library that solves such problems to be widely adopted. But frameworks always bring a new set of problems of their own, which is why no one is ever going to agree on the subject of those.

There was a lot of JS the language progress but nothing that adds this kind of features. Browsers need to fix those bare bone widgets like the select, the scrollbar, add GridViews etc otherwise developers will use some random, low quality ones .

There is no need that browsers select things that are agreed but 100% of people, it needs to satisfy the needs of a large majority that need to create boring and stabe websited or applications.

React feels safe to me at this point, look at all the JS frameworks it has coexisted with that are now virtually unused. It is stronger than ever and I see it’s future as more of a jQuery than an Angular 1.

Did the tools stabilize though?

I am wondering if in a few years you can pull a project from Github, run npm, gulp (or whatever the REAMDE says) and it will just work.

The only problem I see with rails is that it's hard to find devs these days (at least in Europe). Even if they could learn Rails for that project, many I've spoken to wouldn't want to take a job where Rails is required. I just witnessed a project switching from rails to React (for the frontend) because they just couldn't get enough good people willing to use Rails.

I heard this before, but when we tried to find a React dev for the front-end part we couldn't find any either. There are more JS devs for sure, but you also compete with literally everybody for talent.

I kind of get the impression that there is a glut of developers who know/are learning React and a glut of companies that are having trouble finding someone willing or able to use React (at least where I'm located).

That's interesting. This year, for the first time, I've been working with Rails. It wasn't my choice but I've really enjoyed it. A lot just makes sense and it's been so quick to get things from idea to code.

I don't think devs hesitate because Rails (or Ruby in general) isn't good, they hesitate because they hope to gain more relevant experience by working with JS frameworks.

But again, that's just my experience, it may differ for other companies and/or regions.

Rails isn't enough enterprisey (in my opinion..) no firm ever considers rails.. (note, I love rails!)

Have you tried paying more?

> The only problem I see with rails is that it's hard to find devs these days (at least in Europe).

If you need a contractor to help with a Rails project drop me a line (my email's in my profile). Been working with Rails since 2.x days. Not in Europe tho I'm GMT-4.

Why is HN so against people who _enjoy_ engineering? Why should I run some run-of-the-mill stack that has enourgmous legacy cruft and just not "fun". Not every business wants to be sillicon-valley optimized money farm - some people want to do some enjoyable work.

That's fine, but that's not engineering. Bridge designers do not try to build bridges out of materials discovered in the laboratory last month.

Research engineers do. GP said he is not aiming to build a profitable above all else company. Maximizing fun in a hobby seems legit.

For a hobby and for learning it is absolutely fine. The critique is on businesses running that way fmeither since some developers want to drink the cool-aid on the job or since the company wants to be "attractive" riding the hype train. (How else could they attract the best developers? ;) )

Exactly. Look at Eiffel's Folly, for example.

... and bridge designers don't design 'to have fun', but to have structurally sound, cheap and reliable infrastructure tool to cross rivers. Or imagine hiring a construction company for your dream house, realizing only after all is built that they were experimenting and 'having fun' with new unproven materials, construction, wiring etc.

OP's approach is mighty fine for his own endeavors, but if I had such a worker hired, there would be a serious talk about priorities. If no agreement is found even 100x engineer would be let go.

Quantum bridge: its in a superposition of open and closed and will collapse to one of those states when you try to cross. Also its made out of glass and runs on the block chain.

Dear, for your sake only, I am pasting this definition straight from wikipedia -

Engineers, as practitioners of engineering, are professionals who invent, design, analyze, build, and test machines, systems, structures and materials TO FULFILL OBJECTIVES AND REQUIREMENTS WHILE CONSIDERING THE LIMITATIONS IMPOSED BY PRACTICALITY, REGULATION, SAFETY, AND COST.

The exact reason why most software engineers aren't really engineers.

Yes. This. There are only 700 software engineers in my province. I'm pretty sure not many are working on front end web development. Yet every front end job posting is "engineer". Just no. You don't get to call yourself a doctor because you are medically-inclined. Same applies to engineer.

If you haven't got SV money behind you that's even more reason to focus on delivering something that works.

Your own project on your own time? Go for it. Clients should get the best fit, most reliable option, not the flavour of the moment.

(That all said, RoR is not a great choice these days as it is a niche skill)

Clients are usually not hiring engineers. They have opinionns on management, on what should be done, on how you should work and in which conditions. They have opinions on you being remote or not, on how you should look like, on your mental health (cf. some pieces on whether people on the spectrum make better employees).

Most of these opinions are not grounded and you can not leverage the related tools to improve the work process.

How surprising is it that, given how few variables we are left with, these variables are heavily over-engineered?

I guess.

Those restrictions you describe are classic hallmarks of a toxic workplace IMHO, and somewhere I would leave as soon as I had the chance. I guess I'm lucky to have that choice.

Assuming your field is web development, what is not a niche skill? It seems the choice of backend frameworks is somewhat fragmented with no clear default winner.

I'm not sure there's an outright winner, but RoR was the hot thing what, 12 years ago?

It can be difficult to recruit for now.

(Also no, I'm not in web development, I have just observed this)

I'm not a Rails developer myself, but definitely noticed a lot of demand for Rails work in the various remote job newsletters I'm subscribed to. Can't say how much is legacy vs greenfield or whether this is a reflection of demand for a niche skill or that Rails is still a popular choice for companies. Either way, makes me regret a little I didn't stick to Rails development years ago as it seems quite lucrative even today.

RoR is absolutely not a niche skill-there a huge companies using it (GitHub, Shopify), tons of conferences on it (and a lot of Ruby conferences are heavily Rails), and my company personally has had no trouble recruiting devs. StackOverflow puts it at 8% absolutely popularity while Express is at 17%, so just little less than 50%, so it’s not niche just not in the top 3 backend web frameworks.

Because real engineers enjoy making hard things boring.

edit: to be clear, I'm not claiming to be a 'real' engineer. I love writing whimsical, complicated stuff if it makes things easier for users, and make sure I'm writing maintainable code my colleagues are comfortable with with code reviews and removing as many flourishes as possible.

I'm sure I read a definition of engineering once that was basically "meet the requirements doing as little new as possible".

If you want to hack on new technologies, great, that's understandable. But do that on your own time, not when you're being paid to achieve business objectives.

This is how you kill innovation pretty effectively, especially considering the usual length of workdays in our industry.

Remember: You will not retain talent if you want them to act like code monkeys.

I love engineering. I don't love over-engineering.

I also love to experiment with new interesting stuff. But that's not engineering, it's learning.

It s not fun at all 2 years later though

And it s debateable if learning other people’s apis is fun

My first thought was "I wish the startup I'm working for would read this". My second, "eh, wouldn't change anything."

> so I’m working on a new website and series of engineering posts to help share my approach to a lot of these problems.

Do you have a mailing list or something to get on to get updated on this?

I will hunt down this comment and reply to you in your profile once it’s out!

Me too, please.

Please, I too would like to know

Hunt me also.

And me please

However, the post indicates React + Redux for the front-end. Perhaps it's my bias as a back-end curmudgeon, but those strike me as _unboring_ choices in the front end, particularly if you're not targeting SPAs.

My point being: one person's "boring" could be another person's anything from "clunky and archaic" to "faddy" to "efficient and sensible." Not even Rails, built upon Ruby's idiosyncratic blood magick, is an entirely uncontroversial choice.

So, boredom is in the eye of the beholder?

I agree with your overall point, however I disagree with the "just pick Rails and don't do SPA" part. For startups or any small team, the right approach is whatever boring technologies the team is comfortable with. If that is Rails, great! I personally don't know it so that would be a horrible choice for me. Likewise SPAs are comfortable and easy for me (aka boring), but a bad choice for someone else who isn't comfortable with them.

I think Phoenix LiveView is offering a very compelling value here. You are basically writing a regular server side app that will perform on par with SPA for most use cases.

What is it that Rails has that Node.js doesn't?

Node.js is missing a great ORM but other than that I don't see many things missing in Node.js anymore.

There is also Rails' admin panel but most projects don't need that.

I’m not sure if you’re familiar with what Rails really is. It doesn’t have an admin panel.

Node is a language that you could compare to Ruby.

You can ostensibly do the exact same thing with Node that you could do with Ruby on Rails... but you’d be reinventing the wheel all over the place and duct taping lots of different modules together that all utilize different design patterns.

If you’re good at designing systems, you can do it just fine, albeit slower than I could with Rails. But it’s possible. I have nothing against Node but there’s a time and a place for all tools. Getting an MVP up is not one of them, imho.

Check the top comments here https://news.ycombinator.com/item?id=20920555

I wonder what is wrong with single page apps? As I see it you can largely write the same code, you just have the additional option of modifying the page on the fly.

Nothing wrong with it if you know what you’re doing and have a strong API to power it. Most people don’t know what they’re doing and end up with a duct taped ball or spaghetti. This tendency is compounded when you’re in a hurry to get shit done.

Nothing better than having to maintain 1000 line components. I wouldn't know, but I have dumped them on other people. It made sense to me when I frantically wrote it, how bad could it be? /s

But is the server side method less spaghetti-prone? I'm inclined to believe that you just believe that because it is the way you are used to programming. A beginner will write spaghetti no matter the job, no matter the tools, no matter the method.

Nothing "wrong" with them per se, but in terms of system complexity, you're basically doubling it by having application state and logic on both the backend and frontend. When I work on a big SPA, I feel like I'm working on two applications and have to worry about syncing state and logic together.

>> It hurts to see people continue to make mistakes over and over,

Its because

https://vimeo.com/76499047

If you do write something up, I'd like to read it - solid analysis re systems architecture et al.

Got your email in my notes. Will shoot you a message once I have something out.

I would go with spring boot. Sure rails is a faster start, but when it grows it becomes a mess. Spring boot gives you the fastest start in JVM-land, and if your product is successful and you need things to scale, or features are getting complex, you still have the spring framework in the insides that you can manage. Boot is almost just defaults.

But spring boot wouldn't exist, if rails didn't change the landscape of web development.

Reply on news.ycombinator.com