Ask HN: F***ing 2021 Front-End Dev: How to dev faster?
2 comments
I think treating the back end and front end separately is the royal road to "slow development".
Look at what Lotus Notes accomplished in the 1990s, realize all the patents have run out, and put that together with the possibilities of websockets, systems like React and Phoenix.
Another world is possible.
Look at what Lotus Notes accomplished in the 1990s, realize all the patents have run out, and put that together with the possibilities of websockets, systems like React and Phoenix.
Another world is possible.
> Look at what Lotus Notes accomplished in the 1990s
Could you please develop your idea?:)
Lotus Notes was based around a document database, long before document databases were cool.
Patents concerned many things, but the most valuable of which was that the system could merge changes to the documents made by different users and even had a system for manual exception handling when the automated algorithm didn't work.
Notes was oriented towards workflows where several users might need to contribute actions towards completing a ticket. In 2021 some of parts of the workflow might be completed by an A.I. or might involve an IoT system that takes measurements or physical actions.
With websockets and similar tech, the UI ought to update automatically when the state of the system changes. You might not even notice that steps in a workflow happened if they happened quickly enough.
One feature of Lotus Notes that nobody would try today (email software is mostly about resilience to cyberattacks today) was that Lotus Notes had an integrated email client. That would be helpful if the application is "an email gets sent to the company and several people coordinate in replying to it",
The core concept I want to push is that the real area where applications get in trouble is with the back end database. If you made a bad decision five years ago you might be living with it for the next twenty years or if you are lucky your product will EOL soon because of it.
To take one example, in one month I worked on two legacy systems that had database tables with twelve or so datetime fields to keep track of important events in the history of a student (from pre-application to alumni) or a shipping pallet. Turned out that some of these objects didn't take straight line trajectories through the system (data was wrong and corrupted) and it's a bear to write queries to ask things like "where was Pallet X on April 9, 2004?"
A single database structure (object id, state, start_time, end_time) works to keep track of a changing state. If you ask developers to reinvent the wheel they'll probably do it wrong. A true "low code" system would have schemas built in that represent things like this the right way... So the easy way, the default way, is the right way.
Patents concerned many things, but the most valuable of which was that the system could merge changes to the documents made by different users and even had a system for manual exception handling when the automated algorithm didn't work.
Notes was oriented towards workflows where several users might need to contribute actions towards completing a ticket. In 2021 some of parts of the workflow might be completed by an A.I. or might involve an IoT system that takes measurements or physical actions.
With websockets and similar tech, the UI ought to update automatically when the state of the system changes. You might not even notice that steps in a workflow happened if they happened quickly enough.
One feature of Lotus Notes that nobody would try today (email software is mostly about resilience to cyberattacks today) was that Lotus Notes had an integrated email client. That would be helpful if the application is "an email gets sent to the company and several people coordinate in replying to it",
The core concept I want to push is that the real area where applications get in trouble is with the back end database. If you made a bad decision five years ago you might be living with it for the next twenty years or if you are lucky your product will EOL soon because of it.
To take one example, in one month I worked on two legacy systems that had database tables with twelve or so datetime fields to keep track of important events in the history of a student (from pre-application to alumni) or a shipping pallet. Turned out that some of these objects didn't take straight line trajectories through the system (data was wrong and corrupted) and it's a bear to write queries to ask things like "where was Pallet X on April 9, 2004?"
A single database structure (object id, state, start_time, end_time) works to keep track of a changing state. If you ask developers to reinvent the wheel they'll probably do it wrong. A true "low code" system would have schemas built in that represent things like this the right way... So the easy way, the default way, is the right way.
couldn't agree more.
Then you can upvote if you want, friend ;-) (so more frontend dev colleagues would read and possibly discuss this thread)
You know what? I actually find that 2021 front-end development has a problem of productivity.
A. Big. F*ing. Sh*ty. Problem of productivity.
Read below, my dudes.
Front-end development is better than back-end to making deadlines fly away like gulls. ;-) -> Front-end choose their techs by thinking about speeds. But not the good ones. i. Speed of frontend execution at client-side. ii. Speed of transfer of the frontend from the server to the client. iii. Even speed of execution of the frontend... backside (NextJS). -> BUT F* MY GUYS. YOU KNOW THE F*ING WHAT? Nowadays, Internet taken as a whole is so fast, servers are so fast, clients are so fast, all is so fast that looking for fast front-end fetching queries to the server and/or for execution gains of the frontend is shallow, overengineering, USELESS. So why are you thinking about those speeds again and again and again. You would have better to throw your watermelon to the trash.
What would be welcome and ACTUALLY USEFUL? I answer you in two words, 7 letters ;-). FAST. DEV. FAST DEVELOPMENT, fucking JESUS. (Well the whole list would be: fast dev + super UX-design). The other speeds? Don't care. Blablabla. Don't. F*ing. Care.
Trust me. Trust the speed of dev. It's the FUTURE.
1. What would be very useful: a kind of WYSIWYG to create responsive and UX-designed GUI for webapps and websites. You would be able to bind your WYSIWYG widgets to some logic (NodeJS Nest.JS or PHP Laravel) and both frontend and logic would be bound to some model (Strapi). You would choose the good techs in order to maximize speed of development. Should this WYSIWYG tech be open-source, proprietary, self-hosted, cloud-hosted, should it output dependent webapp/websites or actual, i.e. self-sufficiently executing webapp/websites, should this WYSIWYG be subject to versioning, all of these questions = I have my own opinion but yeah;
2. What would be useful if this tech doesn't yet exist in 2021: a fast dev frontend framework (or more exactly I should rather say: a fast dev frontend widgets&design library).
NOW MY GUYS. Read again bellow AND TRY IT.
1. Open HackerNews. Or Google. Type "low code frontend", "low-code frontend", "lowcode front-end" and whatever the syntax you want. What you will find are only 2 or 3 solutions. All except one cost the ass and are proprietary (not even open-source wtf). The last one, AppSmith, is for internal projects only (don't allow us to do responsive designs/widgets).
2. Open HackerNews....... Google.... Type "frontend" and read 10 first pages like I did. You will mostly find Next.JS + Ant design or Svelte. But are they really fast dev? Nooope my dude, nope nope nope, they just have a learning curve faster than React ;-).
You guys, I actually find that 2021 front-end development has a problem of productivity.
A. Big. F*ing. Sh*ty. Problem of productivity.