6 ms·

To jump off the treadmill is not using a fronted framework: at all, and not using a random one and not rewriting the code later. Server side rendering, JavaScri

To jump off the treadmill is not using a fronted framework: at all, and not using a random one and not rewriting the code later. Server side rendering, JavaScript only when needed, no separation between backend and frontend folks in the company.

klysm 2y ago
No separation between backend and front end is hard. I’m not good at front end, and we don’t have a designer. I’m miles better on backend though and other team members are more talented than me for front end design.
- mmaurizi 2y ago
  Design shouldn't be part of front end engineering - there is a reason there is a separate role for that, designer.
  - klysm 2y ago
    Yeah I agree, but we don't have a designer so what am I to do? I think I'm good at the frontend engineering as in breaking down component structure, passing data around etc. but I can't make something look good enough to meet my own standards.
- singron 2y ago
  You would probably be decent at frontend if you did it at least 20% of the time. Obviously you can't be an expert at everything, but there is enormous value in being able to work on most things end to end instead of having to handoff every time.
  - klysm 2y ago
    I do it about 40% of the time - I'm just straight up not good at it, which is okay. I can get by, but it would be better for the company for somebody else to be doing it. Specialization can be good!
ForTheKidz 2y ago
Javascript doesn't have a good enough standard library to execute on this. You need frameworks just to patch up the runtime (or otherwise avoid the holes). Last time I checked they didn't even have decent hashmap or set implementations (let alone decent serde support).
- wbobeirne 2y ago
  This was true in the lodash and jquery as essential days, but hasn't been the case for years. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  - ForTheKidz 2y ago
    Ah, I stand corrected. I have more recent examples but I struggle to recall them. Map and Set were certainly the two largest absences I remember.
    - stank345 2y ago
      Yeah, those were two big sticking points. There's also Object.groupBy() now which was another thing I always missed from the standard library. Proposals tend to get adopted at a snail's place but it's neat to see what's coming down the pike: https://github.com/tc39/proposals https://github.com/tc39/proposals
    - runako 2y ago
      Worth noting that those features were indeed added after the creation of e.g. React, but both have been widely available for ~10 years now.
  - romellem 2y ago
    > hasn't been the case for years For 10 years, actually. ES6 - otherwise known as ECMAScript 2015 - did in fact come out 10 years ago. - https://en.wikipedia.org/wiki/ECMAScript_version_history#6th_Edition_%E2%80%93_ECMAScript_2015 https://en.wikipedia.org/wiki/ECMAScript_version_history#6th... It truly did improve the JS landscape by an order of magnitude. For those unfamiliar with the extensive features this brought to JS, here is a good list: - https://rse.github.io/es6-features/ https://rse.github.io/es6-features/
mangodrunk 2y ago
Well said. The BE / FE split has been a really bad experiment. It has exasperated the issue where the FE is overly complex because there are people on a FE team, so they toil away and just add complexity. It is also problematic that we have so many people who only know web development and nothing else.
- gryn 2y ago
  As someone who's been on teams/products that did away with the front/back separation back in the php era I think that's a terrible idea. When things go wrong, which they will given enough time, size and complexity, the blast radius is much bigger. I still remember trying to change an onboarding page on a website only to find code with goto statements that jump to places that does db calls, messes with code for c processes that supposed to run on an embedded devices (they shared the same codebase), the include statements that executed stuff and had a non trivial call graph that made it hard to refactor, etc. Meanwhile when things went real wrong on team/projects with bad frontend you could just nuke it (and maybe the people who made it) and restart another frontend in parallel, instead of preparing an excavation taskforce to carefully split the back from the front. Now I know the first reaction would be duh just have a separation between the concerns and don't write shit code, but I'm talking about when things go wrong (maybe before you got there). The FE/BE split is one of those lessons that I'm thankful managers learned.
  - happimess 2y ago
    I think you're conflating the coders with the code. I read the upthread comments as advocating against dedicated FE/BE coders, not against dedicated FE/BE code bases. Of course you want your embedded C separate from your CSS! The critique, I think, is that you don't want a front end team, because if your front end is in good shape, then they'll change things just to keep busy.
  - mejutoco 2y ago
    I wonder what you think of components. Back in the day it was heresy to mix css html and js. Everything was separated. Nowadays a component mixes them all. In a way, it is exactly the example opposite of what you mention.
kerkeslager 2y ago
It's amazing what CSS can do these days. I'm working on a side project where one of my initial constraints was I wanted the entire site to degrade gracefully when JavaScript was disabled. This led me to a situation where whenever I wanted to add some function that would typically be done with JavaScript, I'd ask, "Can I do this without JavaScript?" To my surprise, the answer so far has always been yes. It's amazing what CSS selectors on basic HTML controls can do these days. There's still not a line of JS in that codebase.
zwnow 2y ago
Yea people should just learn Elixir/Phoenix and forget about all their npm js issues...
bob1029 2y ago
> no separation between backend and frontend folks in the company. This is the biggest gain available anywhere. When you have one engineer who is empowered to write SQL specifically crafted to pull the exact columns required to SSR a web view (which they are also responsible for), you don't need to spend a single second thinking about APIs or ORMs or whatever. You just need to know SQL and modern vanilla HTML/CSS/JS. The server-side programming ecosystem really starts to take a back seat since most of what you are doing is transforming views of the business (SQL) to DOM (HTML). I think the end game is doing SSR of web content inside the RDBMS (e.g., Oracle APEX), but most engineers aren't ready for that conversation yet. I know I wasn't when I saw it for the first time in the wild. We're very attached to our modes of suffering.
- koakuma-chan 2y ago
  > I think the end game is doing SSR of web content inside the RDBMS OR just embed the RDBMS into your application!
  - bob1029 2y ago
    SQLite is certainly a very good option. You could bind a handful of UDFs and turn it into a poor man's Oracle stack. https://www.sqlite.org/appfunc.html https://www.sqlite.org/appfunc.html
    - koakuma-chan 2y ago
      It's also very easy to do in Rust. https://github.com/rusqlite/rusqlite/blob/master/examples/loadable_extension.rs https://github.com/rusqlite/rusqlite/blob/master/examples/lo...
- rpmisms 2y ago
  Does writing HTML into database entries count? Because certain large entertainment companies are ahead of the curve if so.
  - 2y ago
robertoandred 2y ago
So you're just jumping on the backend treadmill.
roflyear 2y ago
Yeah, agreed - but I do think using vue, react, whatever on certain pages really has its benefits. Sometimes a UI really is improved by using features that Vue makes really easy to implement. Of course it's possible without Vue - but you have to do a lot more work in many cases... so, what's the point?
whstl 2y ago
I agree 100%, but "JavaScript only when needed" is a loaded phrase. Especially when you don't have an engineering-centric culture. Product/Design teams will kick and scream into getting you to add as much javascript tchotchkes as possible with zero regard for usability, performance, accessibility or good engineering.

klysm 2y ago

No separation between backend and front end is hard. I’m not good at front end, and we don’t have a designer. I’m miles better on backend though and other team members are more talented than me for front end design.

mmaurizi 2y ago
Design shouldn't be part of front end engineering - there is a reason there is a separate role for that, designer.
- klysm 2y ago
  Yeah I agree, but we don't have a designer so what am I to do? I think I'm good at the frontend engineering as in breaking down component structure, passing data around etc. but I can't make something look good enough to meet my own standards.
singron 2y ago
You would probably be decent at frontend if you did it at least 20% of the time. Obviously you can't be an expert at everything, but there is enormous value in being able to work on most things end to end instead of having to handoff every time.
- klysm 2y ago
  I do it about 40% of the time - I'm just straight up not good at it, which is okay. I can get by, but it would be better for the company for somebody else to be doing it. Specialization can be good!

ForTheKidz 2y ago

Javascript doesn't have a good enough standard library to execute on this. You need frameworks just to patch up the runtime (or otherwise avoid the holes). Last time I checked they didn't even have decent hashmap or set implementations (let alone decent serde support).

wbobeirne 2y ago
This was true in the lodash and jquery as essential days, but hasn't been the case for years. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- ForTheKidz 2y ago
  Ah, I stand corrected. I have more recent examples but I struggle to recall them. Map and Set were certainly the two largest absences I remember.
  - stank345 2y ago
    Yeah, those were two big sticking points. There's also Object.groupBy() now which was another thing I always missed from the standard library. Proposals tend to get adopted at a snail's place but it's neat to see what's coming down the pike: https://github.com/tc39/proposals https://github.com/tc39/proposals
  - runako 2y ago
    Worth noting that those features were indeed added after the creation of e.g. React, but both have been widely available for ~10 years now.
- romellem 2y ago
  > hasn't been the case for years For 10 years, actually. ES6 - otherwise known as ECMAScript 2015 - did in fact come out 10 years ago. - https://en.wikipedia.org/wiki/ECMAScript_version_history#6th_Edition_%E2%80%93_ECMAScript_2015 https://en.wikipedia.org/wiki/ECMAScript_version_history#6th... It truly did improve the JS landscape by an order of magnitude. For those unfamiliar with the extensive features this brought to JS, here is a good list: - https://rse.github.io/es6-features/ https://rse.github.io/es6-features/

mangodrunk 2y ago

Well said. The BE / FE split has been a really bad experiment. It has exasperated the issue where the FE is overly complex because there are people on a FE team, so they toil away and just add complexity. It is also problematic that we have so many people who only know web development and nothing else.

gryn 2y ago
As someone who's been on teams/products that did away with the front/back separation back in the php era I think that's a terrible idea. When things go wrong, which they will given enough time, size and complexity, the blast radius is much bigger. I still remember trying to change an onboarding page on a website only to find code with goto statements that jump to places that does db calls, messes with code for c processes that supposed to run on an embedded devices (they shared the same codebase), the include statements that executed stuff and had a non trivial call graph that made it hard to refactor, etc. Meanwhile when things went real wrong on team/projects with bad frontend you could just nuke it (and maybe the people who made it) and restart another frontend in parallel, instead of preparing an excavation taskforce to carefully split the back from the front. Now I know the first reaction would be duh just have a separation between the concerns and don't write shit code, but I'm talking about when things go wrong (maybe before you got there). The FE/BE split is one of those lessons that I'm thankful managers learned.
- happimess 2y ago
  I think you're conflating the coders with the code. I read the upthread comments as advocating against dedicated FE/BE coders, not against dedicated FE/BE code bases. Of course you want your embedded C separate from your CSS! The critique, I think, is that you don't want a front end team, because if your front end is in good shape, then they'll change things just to keep busy.
- mejutoco 2y ago
  I wonder what you think of components. Back in the day it was heresy to mix css html and js. Everything was separated. Nowadays a component mixes them all. In a way, it is exactly the example opposite of what you mention.

kerkeslager 2y ago

It's amazing what CSS can do these days. I'm working on a side project where one of my initial constraints was I wanted the entire site to degrade gracefully when JavaScript was disabled. This led me to a situation where whenever I wanted to add some function that would typically be done with JavaScript, I'd ask, "Can I do this without JavaScript?" To my surprise, the answer so far has always been yes. It's amazing what CSS selectors on basic HTML controls can do these days. There's still not a line of JS in that codebase.

zwnow 2y ago

Yea people should just learn Elixir/Phoenix and forget about all their npm js issues...

bob1029 2y ago

> no separation between backend and frontend folks in the company. This is the biggest gain available anywhere. When you have one engineer who is empowered to write SQL specifically crafted to pull the exact columns required to SSR a web view (which they are also responsible for), you don't need to spend a single second thinking about APIs or ORMs or whatever. You just need to know SQL and modern vanilla HTML/CSS/JS. The server-side programming ecosystem really starts to take a back seat since most of what you are doing is transforming views of the business (SQL) to DOM (HTML). I think the end game is doing SSR of web content inside the RDBMS (e.g., Oracle APEX), but most engineers aren't ready for that conversation yet. I know I wasn't when I saw it for the first time in the wild. We're very attached to our modes of suffering.

koakuma-chan 2y ago
> I think the end game is doing SSR of web content inside the RDBMS OR just embed the RDBMS into your application!
- bob1029 2y ago
  SQLite is certainly a very good option. You could bind a handful of UDFs and turn it into a poor man's Oracle stack. https://www.sqlite.org/appfunc.html https://www.sqlite.org/appfunc.html
  - koakuma-chan 2y ago
    It's also very easy to do in Rust. https://github.com/rusqlite/rusqlite/blob/master/examples/loadable_extension.rs https://github.com/rusqlite/rusqlite/blob/master/examples/lo...
rpmisms 2y ago
Does writing HTML into database entries count? Because certain large entertainment companies are ahead of the curve if so.
- 2y ago

robertoandred 2y ago

So you're just jumping on the backend treadmill.

roflyear 2y ago

Yeah, agreed - but I do think using vue, react, whatever on certain pages really has its benefits. Sometimes a UI really is improved by using features that Vue makes really easy to implement. Of course it's possible without Vue - but you have to do a lot more work in many cases... so, what's the point?

whstl 2y ago

I agree 100%, but "JavaScript only when needed" is a loaded phrase. Especially when you don't have an engineering-centric culture. Product/Design teams will kick and scream into getting you to add as much javascript tchotchkes as possible with zero regard for usability, performance, accessibility or good engineering.