4 ms·

This comment hits the nail right on the head. What is wrong with web dev? Why is it perceived not ok to be "stuck in 2015"? I've never seen so much churn and t

by k_sze 6y ago

This comment hits the nail right on the head. What is wrong with web dev? Why is it perceived not ok to be "stuck in 2015"? I've never seen so much churn and turnover in any other single layer of a tech stack.

lecarore 6y ago
The tech stack in front-end changes constantly because things change : new constrain (mobile), new possibilities (webrtc, WebWorkers), new expectations (people sometimes don't just want a document), new Frameworks that attempt to solve previous problems better (react), and new trends (material UI) that require not just a css change. It's not perfect, but given how much the ground shifts below your feets constantly while you maintain your web app, I don't find the experience that bad. Make an static html document if you need a document. Make backend code with a sprinkle of vanilla js if you make simple interactions. Use react if you need your app to evolve fast, do tons of things, and stay organised. That's what I do for my project, ciboulette.net . The marketing website is static and js free. The UI to pass an order is an express server, html pages with a sprinkle of js. The administration UI is react + meteorjs. And it's fine, not perfect, but I don't feel like it's too much.
ZephyrBlu 6y ago
There isn't massive churn. As far as I can see, most of the JS ecosystem has been continually improving. React has been around since 2013 [0], Webpack has been around since 2014 [1], etc. If you're stuck in 2015, you're 5 years of updates and improvements behind. The author, by his own account, does not want to keep up with the evolution of the ecosystem: "I suppose with the increase of complexity in what we want to achieve on the web the stack to achieve it with has had to also increase in complexity. For me, personally, it's too much". [0] https://en.wikipedia.org/wiki/React_(JavaScript_library) https://en.wikipedia.org/wiki/React_(JavaScript_library) [1] https://en.wikipedia.org/wiki/Webpack https://en.wikipedia.org/wiki/Webpack
mhoad 6y ago
I mentioned this in another comment above but for anyone feeling this way which I think is entirely reasonable and healthy even there are two options I would point them towards both at totally different ends of the spectrum. The first one is for people who are mostly comfortable with backend development and want to have as little to do with the mess that is the churn of front end as possible. However for those people I would strongly recommend taking a serious look at Hotwire.dev which is a new approach from the same team behind Ruby on Rails and their vision of trying to bring that same level of simplicity to the front end. It does a great job on that angle in particular and for most applications is likely to be entirely appropriate for your needs. They built it specifically while developing a modern web based email client so it scales up to fairly decent levels of complexity while still maintaining probably 85% of the performance of the standard SPA approach. But if you specifically want simplicity this is the best option out there I know of currently. The other end of the spectrum is Angular which is all in on the SPA approach and everything that involves however it has a number of key differences between other frameworks that I think make it the “front end framework of choice for enterprise applications”. It’s extremely stable both in terms of bugs, performance and API. Every code change for example that lands in main is tested against almost 3000 different applications full test suites inside of Google and I believe (not entirely sure if this is correct or not) but also a number of other enterprises in addition to that. You are mostly going to be writing code as though you were just writing a regular application because it was specifically designed to sit on top of the web rather than trying to expose all the moving targets of the web platform and its various APIs directly to developers. I can not stress how much this can reduce headaches out of the box. Basically the way I look at angular is Google said here is an approach that we have found works really well for writing apps that scale in terms of performance and code based. You won’t be able to outgrow this no matter how big you get and it’s what we use to run almost all of our customer facing revenue generating parts of the business (ads and cloud). The approach is about as well tested as well you could possibly find. In addition to that if you follow our opinionated approach and APIs we are going to allow you to have a great developer experience. One main example of this is Angular has a rolling release cycle now where the tooling is able to upgrade your code base for you with each new release meaning you have no excuse for staying on the happy path. But on the whole the idea of front end churn is a thing of the past this way. Additionally, behind the API that you are going to be exposed to Google are throwing a lot of “computer science” fire power at problems like performance and general engineering best practices etc but basically you can just outsource most of that part of the problem to the Angular team. Disclaimer: it’s not magic, it’s still possible to write bad apps and even recently on here you will have heard people talk about Google cloud as a good example but it seemed like a lot of the reasons for that based on the inside baseball comments I read here had more to do with culture, product velocity and the sheer number of teams who weren’t working in coordination with each other. I still stand by the idea that the idea however that the sheer insane amounts of money Google has betting on Angular means that it is only going to get better and better over time at those issues.
- dmpk2k 6y ago
  You're making it sound like Hotwire is some novel thing the RoR guys have come up with. It's actually a copy of Phoenix LiveView, and not the only one either.
  - danjac 6y ago
    Turbolinks came out around 2012, Hotwire is just the latest iteration of that. Phoenix didn't exist until 2014.
    - dmpk2k 6y ago
      Saying Hotwire is the latest iteration of Turbolinks is like saying C++ is the latest iteration of C.

by k_sze 6y ago

lecarore 6y ago

The tech stack in front-end changes constantly because things change : new constrain (mobile), new possibilities (webrtc, WebWorkers), new expectations (people sometimes don't just want a document), new Frameworks that attempt to solve previous problems better (react), and new trends (material UI) that require not just a css change. It's not perfect, but given how much the ground shifts below your feets constantly while you maintain your web app, I don't find the experience that bad. Make an static html document if you need a document. Make backend code with a sprinkle of vanilla js if you make simple interactions. Use react if you need your app to evolve fast, do tons of things, and stay organised. That's what I do for my project, ciboulette.net . The marketing website is static and js free. The UI to pass an order is an express server, html pages with a sprinkle of js. The administration UI is react + meteorjs. And it's fine, not perfect, but I don't feel like it's too much.

ZephyrBlu 6y ago

There isn't massive churn. As far as I can see, most of the JS ecosystem has been continually improving. React has been around since 2013 [0], Webpack has been around since 2014 [1], etc. If you're stuck in 2015, you're 5 years of updates and improvements behind. The author, by his own account, does not want to keep up with the evolution of the ecosystem: "I suppose with the increase of complexity in what we want to achieve on the web the stack to achieve it with has had to also increase in complexity. For me, personally, it's too much". [0] https://en.wikipedia.org/wiki/React_(JavaScript_library) https://en.wikipedia.org/wiki/React_(JavaScript_library) [1] https://en.wikipedia.org/wiki/Webpack https://en.wikipedia.org/wiki/Webpack

mhoad 6y ago

I mentioned this in another comment above but for anyone feeling this way which I think is entirely reasonable and healthy even there are two options I would point them towards both at totally different ends of the spectrum. The first one is for people who are mostly comfortable with backend development and want to have as little to do with the mess that is the churn of front end as possible. However for those people I would strongly recommend taking a serious look at Hotwire.dev which is a new approach from the same team behind Ruby on Rails and their vision of trying to bring that same level of simplicity to the front end. It does a great job on that angle in particular and for most applications is likely to be entirely appropriate for your needs. They built it specifically while developing a modern web based email client so it scales up to fairly decent levels of complexity while still maintaining probably 85% of the performance of the standard SPA approach. But if you specifically want simplicity this is the best option out there I know of currently. The other end of the spectrum is Angular which is all in on the SPA approach and everything that involves however it has a number of key differences between other frameworks that I think make it the “front end framework of choice for enterprise applications”. It’s extremely stable both in terms of bugs, performance and API. Every code change for example that lands in main is tested against almost 3000 different applications full test suites inside of Google and I believe (not entirely sure if this is correct or not) but also a number of other enterprises in addition to that. You are mostly going to be writing code as though you were just writing a regular application because it was specifically designed to sit on top of the web rather than trying to expose all the moving targets of the web platform and its various APIs directly to developers. I can not stress how much this can reduce headaches out of the box. Basically the way I look at angular is Google said here is an approach that we have found works really well for writing apps that scale in terms of performance and code based. You won’t be able to outgrow this no matter how big you get and it’s what we use to run almost all of our customer facing revenue generating parts of the business (ads and cloud). The approach is about as well tested as well you could possibly find. In addition to that if you follow our opinionated approach and APIs we are going to allow you to have a great developer experience. One main example of this is Angular has a rolling release cycle now where the tooling is able to upgrade your code base for you with each new release meaning you have no excuse for staying on the happy path. But on the whole the idea of front end churn is a thing of the past this way. Additionally, behind the API that you are going to be exposed to Google are throwing a lot of “computer science” fire power at problems like performance and general engineering best practices etc but basically you can just outsource most of that part of the problem to the Angular team. Disclaimer: it’s not magic, it’s still possible to write bad apps and even recently on here you will have heard people talk about Google cloud as a good example but it seemed like a lot of the reasons for that based on the inside baseball comments I read here had more to do with culture, product velocity and the sheer number of teams who weren’t working in coordination with each other. I still stand by the idea that the idea however that the sheer insane amounts of money Google has betting on Angular means that it is only going to get better and better over time at those issues.

dmpk2k 6y ago
You're making it sound like Hotwire is some novel thing the RoR guys have come up with. It's actually a copy of Phoenix LiveView, and not the only one either.
- danjac 6y ago
  Turbolinks came out around 2012, Hotwire is just the latest iteration of that. Phoenix didn't exist until 2014.
  - dmpk2k 6y ago
    Saying Hotwire is the latest iteration of Turbolinks is like saying C++ is the latest iteration of C.