12 ms·

It's been an interesting ride the past few years as a software engineering manager: many junior engineers have never developed or deployed anything that require

by HNTA_1 5y ago

It's been an interesting ride the past few years as a software engineering manager: many junior engineers have never developed or deployed anything that requires Apache httpd. Some have never even heard of it, or seen it in the wild.

orf 5y ago
Is that unexpected?
- rbanffy 5y ago
  Well… I was a bit surprised to find a Teams group about VMS application support in my company… perhaps I shouldn’t. After all, we also have a lot of IBM mainframes being used too and, most likely, other exotic stuff in areas I don’t even know about that exist way above my security clearance.
- HNTA_1 5y ago
  Considering it still runs a large percentage of the WWW, I would say it is a bit unexpected.
alexpotato 5y ago
I've seen a similar effect with web design. EVERY page (or site) seems to need a full blown NodeJS server install and tons of React/Vue etc. Younger folks are blown away at how quickly I can develop a fully functional site with just Flask, good ole' HTML, basic CSS and VanillaJS using only a couple flat files as a backend database. I could make a similar argument about complex Python or Golang scripts that are basically the equivalent of multiple bash commands piped into a one liner.
- dreyfan 5y ago
  The toolchains to build and deploy a completely static site today are about 10x more complex than a fully dynamic python/ruby/php site a decade or two ago. I genuinely don’t understand it.
  - FpUser 5y ago
    >"I genuinely don’t understand it." There is no need to. It is insanity. Maybe using truckloads of complex tooling makes one feel smarter never mind that the final outcome is something akin to "Hello World".
    - still_grokking 5y ago
      Some, especially younger folks, sadly just don't know better. Maybe we just experience now the same people back than experienced seeing the new generation using for example C++ instead of some "straight simple lines of assembly". On the other hand's side there is for sure complexity which you actually want to pay for. Whether such call is or isn't justified can't be known upfront often times. Given that, my personal opinion on the state of web-development is that it's partly outright insanity for sure. Especially front-end things. Boy, it's just a GUI in the end! Nobody should care about the code as it should be generated by proper design tools anyway. Coding such things by hand shouldn't feed a whole industry branch instead. Creating GUIs is a job for graphics and interaction designers. They should have gotten the proper tools to get their work done (mostly) on their own. If the alleged "GUI stack" used is so over-complex that it can't be handled effectively by design tooling it's a valid question whether that technology is actually the right tool for the job. But it seems almost nobody is asking this question any more. That's the insane part.
      - FpUser 5y ago
        >"Maybe we just experience now the same people back than experienced seeing the new generation using for example C++ instead of some "straight simple lines of assembly"" I do not think there is any similarity. Personally I've started with straight machine codes, never mind assembly. Still I gladly use any higher level tools as long as they benefit my ROI. As for GUI - back in the 90s Borland had already shown how to produce stellar, easy to use performant tools for designing GUI apps. JS public has had ages to come up with something resembling the same thing. Instead they've unleashed whole bunch of atrocities making themselves into their own victims with all signs of Stockholm's syndrome.
- saila 5y ago
  I work with Node and Python regularly and I'm unclear on how a Node stack would be more complex than a Python stack. Isn't "just Flask," which is Python plus packages, equivalent to Node plus packages, both in terms of development and deployment?
  - bern4444 5y ago
    Yes, to me at least. The parent comment maybe just knows flask very well and is more comfortable with it and less comfortable with JS. An equivalently proficient JS engineer would be able to do just as much in just as little time (and likely more anyway). Personally I think JS is a much better language. Python is still recovering from the 2 to 3 migration. Meanwhile JS will always be backwards compatible and with TS is a great language to work in. Python still doesn't have a good type system.
    - the_duke 5y ago
      Python annotations actually provide a very decent typing layer. You have to use an additional tool to do the checks, there are much fewer third party typings, and the type system is definitely not as sophisticated as TS. But Python code is also not as dynamic as JavaScript, so you can get most of the way with what's already in the standard library. (again, disregarding the missing pervasive typings for the ecosystem)
- bern4444 5y ago
  Templating engines are far less powerful and extensible than client side frameworks. FWIW, there are many JS templating engines as well that work with NodeJS too. There are pretty obvious downsides to templating engines that libraries like React and Vue improve upon. Using flat files as a backend database is great, but not scalable. Does everything need to scale, not always, but it's a lot nicer to have that option and to build it that way from the beginning. It's also ridiculously easy to do so today. You'd probably be blown away how quickly someone can get a full stack website set up complete with user authentication/accounts management (including reset flows, magic links etc), database integration, front end system, CMS, component design system, and any other goodies. All this is easily doable in relatively short amounts of time, and makes working with other teams - designers, product owners, marketing teams - so much easier. Not to mention being able to do everything in a single language. That's a huge win. Engineers can hop around easily and have access to the same dependency management system, language features, etc.
  - iJohnDoe 5y ago
    @bernn4444 > You'd probably be blown away how quickly someone can get a full stack website set up complete with user authentication/accounts management (including reset flows, magic links etc), database integration, front end system, CMS, component design system, and any other goodies. > Not to mention being able to do everything in a single language. I’m interested in learning more about this, especially user authentication and and account management. Also, the single language appealing is appealing. I’m from the PHP world of things and need to get experience with what the modern stuff you’re describing. Are there platforms or projects that provide the foundation of what you’re describing?
    - capableweb 5y ago
      > I’m from the PHP world of things and need to get experience with what the modern stuff you’re describing. Are there platforms or projects that provide the foundation of what you’re describing? Clojure and ClojureScript is probably the best real-world and actually practical example of this in the wild. .cljc files can be loaded by any Clojure runtime, while .clj files are for Clojure and .cljs are for ClojureScript. Many of the libraries in the ecosystem all use .cljc, so you can use the same libraries both in the backend and in the frontend.
- rambojazz 5y ago
  > flat files what file formats in particular?
Abishek_Muthian 5y ago
I've not touched any standalone web-server like Apache, nginx over past two years for my web applications because Go's built-in HTTP server is production ready. It's one of my favorite reasons to develop in Go and makes portable deployment a breeze. Lesser number of software to run on the server has resulted in predictable performance and larger savings on cloud costs.
- vbezhenar 5y ago
  What makes a server production ready? For me the reason to use nginx is ease of configuration. Recreating that kind of configuration in code is possible, but tedious and time-consuming.
  - sjtindell 5y ago
    Production ready things are scalable, you can make them highly available, and they are reliable.
    - nix23 5y ago
      Microsoft wants to have a word with you.
  - Abishek_Muthian 5y ago
    Adding to what others have said, I mentioned 'production-ready' specifically because built-in http servers in programming languages are usually for testing and are not supposed to be used in production due to poor performance e.g. Python's http server and hence you'd require a standalone http server with python or Node.js applications. In Go you can use default http server, multiplexer and router to serve your http requests directly to your application logic. It also has support built-in for Lets Encrypt SSL certificate via autocert covering all fundamental reasons you'd want a standalone web server for your web application.

by HNTA_1 5y ago

orf 5y ago

Is that unexpected?

rbanffy 5y ago
Well… I was a bit surprised to find a Teams group about VMS application support in my company… perhaps I shouldn’t. After all, we also have a lot of IBM mainframes being used too and, most likely, other exotic stuff in areas I don’t even know about that exist way above my security clearance.
HNTA_1 5y ago
Considering it still runs a large percentage of the WWW, I would say it is a bit unexpected.

alexpotato 5y ago

I've seen a similar effect with web design. EVERY page (or site) seems to need a full blown NodeJS server install and tons of React/Vue etc. Younger folks are blown away at how quickly I can develop a fully functional site with just Flask, good ole' HTML, basic CSS and VanillaJS using only a couple flat files as a backend database. I could make a similar argument about complex Python or Golang scripts that are basically the equivalent of multiple bash commands piped into a one liner.

dreyfan 5y ago
The toolchains to build and deploy a completely static site today are about 10x more complex than a fully dynamic python/ruby/php site a decade or two ago. I genuinely don’t understand it.
- FpUser 5y ago
  >"I genuinely don’t understand it." There is no need to. It is insanity. Maybe using truckloads of complex tooling makes one feel smarter never mind that the final outcome is something akin to "Hello World".
  - still_grokking 5y ago
    Some, especially younger folks, sadly just don't know better. Maybe we just experience now the same people back than experienced seeing the new generation using for example C++ instead of some "straight simple lines of assembly". On the other hand's side there is for sure complexity which you actually want to pay for. Whether such call is or isn't justified can't be known upfront often times. Given that, my personal opinion on the state of web-development is that it's partly outright insanity for sure. Especially front-end things. Boy, it's just a GUI in the end! Nobody should care about the code as it should be generated by proper design tools anyway. Coding such things by hand shouldn't feed a whole industry branch instead. Creating GUIs is a job for graphics and interaction designers. They should have gotten the proper tools to get their work done (mostly) on their own. If the alleged "GUI stack" used is so over-complex that it can't be handled effectively by design tooling it's a valid question whether that technology is actually the right tool for the job. But it seems almost nobody is asking this question any more. That's the insane part.
    - FpUser 5y ago
      >"Maybe we just experience now the same people back than experienced seeing the new generation using for example C++ instead of some "straight simple lines of assembly"" I do not think there is any similarity. Personally I've started with straight machine codes, never mind assembly. Still I gladly use any higher level tools as long as they benefit my ROI. As for GUI - back in the 90s Borland had already shown how to produce stellar, easy to use performant tools for designing GUI apps. JS public has had ages to come up with something resembling the same thing. Instead they've unleashed whole bunch of atrocities making themselves into their own victims with all signs of Stockholm's syndrome.
saila 5y ago
I work with Node and Python regularly and I'm unclear on how a Node stack would be more complex than a Python stack. Isn't "just Flask," which is Python plus packages, equivalent to Node plus packages, both in terms of development and deployment?
- bern4444 5y ago
  Yes, to me at least. The parent comment maybe just knows flask very well and is more comfortable with it and less comfortable with JS. An equivalently proficient JS engineer would be able to do just as much in just as little time (and likely more anyway). Personally I think JS is a much better language. Python is still recovering from the 2 to 3 migration. Meanwhile JS will always be backwards compatible and with TS is a great language to work in. Python still doesn't have a good type system.
  - the_duke 5y ago
    Python annotations actually provide a very decent typing layer. You have to use an additional tool to do the checks, there are much fewer third party typings, and the type system is definitely not as sophisticated as TS. But Python code is also not as dynamic as JavaScript, so you can get most of the way with what's already in the standard library. (again, disregarding the missing pervasive typings for the ecosystem)
bern4444 5y ago
Templating engines are far less powerful and extensible than client side frameworks. FWIW, there are many JS templating engines as well that work with NodeJS too. There are pretty obvious downsides to templating engines that libraries like React and Vue improve upon. Using flat files as a backend database is great, but not scalable. Does everything need to scale, not always, but it's a lot nicer to have that option and to build it that way from the beginning. It's also ridiculously easy to do so today. You'd probably be blown away how quickly someone can get a full stack website set up complete with user authentication/accounts management (including reset flows, magic links etc), database integration, front end system, CMS, component design system, and any other goodies. All this is easily doable in relatively short amounts of time, and makes working with other teams - designers, product owners, marketing teams - so much easier. Not to mention being able to do everything in a single language. That's a huge win. Engineers can hop around easily and have access to the same dependency management system, language features, etc.
- iJohnDoe 5y ago
  @bernn4444 > You'd probably be blown away how quickly someone can get a full stack website set up complete with user authentication/accounts management (including reset flows, magic links etc), database integration, front end system, CMS, component design system, and any other goodies. > Not to mention being able to do everything in a single language. I’m interested in learning more about this, especially user authentication and and account management. Also, the single language appealing is appealing. I’m from the PHP world of things and need to get experience with what the modern stuff you’re describing. Are there platforms or projects that provide the foundation of what you’re describing?
  - capableweb 5y ago
    > I’m from the PHP world of things and need to get experience with what the modern stuff you’re describing. Are there platforms or projects that provide the foundation of what you’re describing? Clojure and ClojureScript is probably the best real-world and actually practical example of this in the wild. .cljc files can be loaded by any Clojure runtime, while .clj files are for Clojure and .cljs are for ClojureScript. Many of the libraries in the ecosystem all use .cljc, so you can use the same libraries both in the backend and in the frontend.
rambojazz 5y ago
> flat files what file formats in particular?

Abishek_Muthian 5y ago

I've not touched any standalone web-server like Apache, nginx over past two years for my web applications because Go's built-in HTTP server is production ready. It's one of my favorite reasons to develop in Go and makes portable deployment a breeze. Lesser number of software to run on the server has resulted in predictable performance and larger savings on cloud costs.

vbezhenar 5y ago
What makes a server production ready? For me the reason to use nginx is ease of configuration. Recreating that kind of configuration in code is possible, but tedious and time-consuming.
- sjtindell 5y ago
  Production ready things are scalable, you can make them highly available, and they are reliable.
  - nix23 5y ago
    Microsoft wants to have a word with you.
- Abishek_Muthian 5y ago
  Adding to what others have said, I mentioned 'production-ready' specifically because built-in http servers in programming languages are usually for testing and are not supposed to be used in production due to poor performance e.g. Python's http server and hence you'd require a standalone http server with python or Node.js applications. In Go you can use default http server, multiplexer and router to serve your http requests directly to your application logic. It also has support built-in for Lets Encrypt SSL certificate via autocert covering all fundamental reasons you'd want a standalone web server for your web application.