10 ms·

PHP + Ajax scripts or the modern ecosystem dilemma

79 points by seapunk 8y ago

cobythedog 8y ago
I feel like I am missing something. Is this just a blog-response to a comment on HN?
- moreira 8y ago
  It's a series-of-tweets response to a comment, wrapped up in a blogpost-like format. ... Yeah.
- giancarlostoro 8y ago
  The tweet is at the top, but yeah it reads a little weird without the context that it's a bunch of tweets. Source: https://twitter.com/dan_abramov/status/1078388060696576001 https://twitter.com/dan_abramov/status/1078388060696576001
kbenson 8y ago
I would like to point out a middle ground, where I currently reside. Back-end in whatever you want (Perl + Mojolicious for me), and a front end using one of the major frameworks (Vue for me), but without even the need to managing it all with node and NPM (you can still just use script tags, it's not that hard if you don't go crazy with inclusions). Serve pages as simple templates, with maybe some embedded JSON to cut out the initial AJAX request, and now you're playing to the strengths of each part of the stack. You have a back-end that you're comfortable with and possibly have your own library of utilities for, you have a front-end that leverages all the power the browser brings to the table, and you aren't mixing front-end jQuery style actions with back-end templating and the pain that eventually results in.
- giancarlostoro 8y ago
  > with maybe some embedded JSON to cut out the initial AJAX request That's the only hackish portion out of there, otherwise I'd agree. I rather get back what I expect from an endpoint not some mixture of things.
  - kbenson 8y ago
    Well, if you're asking the endpoint for an HTML representation of something, and it responds with template portions and rules for combining them based on data (React,Vue), doesn't it make sense to respond with all the date needed to actually build it right then and there? If someone requests /users.json I return JSON. If someone requests /users.html I return a document with rules in JS for how to build the HTML based on the data (Vue) and the JSON to build it with. In both cases the JSON is the important part, the Vue stuff included in the HTML version is just a transform on that data to be applied by the client. In that respect, I think not including the desired JSON would by hacky, requiring a separate request for the actual data you requested initially.
- azangru 8y ago
  > a front end using one of the major frameworks (Vue for me), but without even the need to managing it all with node and NPM This sounds like such an arbitrarily painful limitation I couldn't resist asking: why? As far as I heard, package managers have been regarded by every language as a blessing. Ruby has its Bundler; Python has its pip; PHP has its Composer (and I heard PHP programmers joke that they feel like grown-ups now, when they have modern tools). Why would you deliberately exclude Node, NPM, and the whole ecosystem that it brings to the table?
  - kbenson 8y ago
    Because I'm literally using Vue, Axios, a polyfill, and Bootstrap-Vue. Two CSS link tags, and four script tags. Currently for external resources, but trivially brought locally. It's an internal web-app, so it's not like minification is even required, much less bundling. No Javascript is used on the back-end currently. To use NPM/yarn/etc, I would have to first install Node, and then configure it to build my stack. At some point if I pull in a bunch of requirements, maybe that's worthwhile, but right now, it's actually a fair amount of work for dubious return given my current needs.
    - azangru 8y ago
      > I would have to first install Node You mean, locally, on your machine? But it's not a big deal. Not even a small deal. It's, like, not a deal at all. But I get your point. I thought you were advocating a general approach, but instead you were describing your specific setup.
      - kbenson 8y ago
        > You mean, locally, on your machine? Well, in this case development is done through Vim on the remote server, first in a dev environment branch, and then pulled from production. It would require installing the tool chain on the server, which is an artifact of my development process, but nevertheless should require consideration in my case. But yeah, I'm just describing my setup, and the ease of which it allows getting started and productive. I'm wasn't really advocating for or against using a build process for the front end in general, just noting my current process. I imagine if I was using a lot of modules in my front-end, I would see the benefit of putting more tooling in place to maintain and manage it fairly quickly.
- ashton314 8y ago
  > Perl, Mojolicious, Vue That's a lovely stack you got there. I'm a Perl guy (sometimes) myself, and I hated all the bloat of the JavaScript tooling. I recently found Vue and I fell in love with how light-weight it is.
jcroll 8y ago
Whatever works but a lot of these modern tools were designed with good reasons and good intentions. Build your mvp with PHP + Ajax, if it's successful tho might not be long till you're hitting a wall and looking for more robust solutions
- wolco 8y ago
  PHP is modern and if you wanted to, you could use the latest laravel framework or microframework with whatever bleeding edge version. If you have a small website plain php/jquery will be faster and simplier to work with.
giancarlostoro 8y ago
Use what you're best at, and if you're paid to use something, use it. If you don't like what you're using at work, take your time to find a new job opportunity. I feel like SPA's are overrated they take away performance and stability from standard HTML websites with some AJAX capabilities thrown in. When I first heard of a SPA it sounded perfect: you download all the HTML you'll ever need once, and load content to the appropriate DIVs accordingly, but now you gotta take a hike and basically do more work to show a button, or a text box, or whatever. I mean no disrespect to people who love SPA web dev, all power to you, but unless I'm paid a lot more, or I'm working on some multimedia / social media type of site, I don't see the point. Sometimes SPA's I see are done poorly which is another pet peeve.
- scarecrowbob 8y ago
  I'm not totally sure about the context for the OP, but just recently there are a lot of folks doing low-end PHP dev work for WordPress, and many of them are now having to learn React because WordPress has changed its backend editor to a system that is based around React. Personally, I think that this is a good choice-- the editor system in that CMS is a very good use case for complex JS technologies. But at the same time, there are a whole lot of of folks who have been doing a lot of work with PHP who didn't want to learn that toolchain. In that context, it's a little complex: we have a whole ecosystem of businesses and developers and software tooling that is being pushed over by some core changes. I'd bet that there are going to be a lot of frustrated low-end PHP devs dragged into learning modern-ish JS tooling.
  - giancarlostoro 8y ago
    Interesting, I knew they had a new editor, since I have a few WordPress blogs, but I only use them, I don't code anything with them, so I hadn't considered how they're rewritten. I don't mind when SPA is used properly, and in this case it only affects one specific use case which makes a lot of sense.
  - arkh 8y ago
    > modern-ish JS tooling This need a lot more scary quotes around modern and tooling. The JS "ecosystem" is a cancer: nowadays when you want to do some front-end work with some CSS you usually end with an install of node and npm/webpack/the-shit-du-jour, half of them crying about incompatibilities and how you should use the shit-du-lendemain instead to compile you don't really don't know what, it still takes 20mn to see the result. All you wanted was to edit some CSS. And surprise: now half of your other projects won't build anymore because you had to install npm-1.911-HELP-ME-DAD and the option to not install globally changed from -not-everywhere to --just-a-local-beer.
altmind 8y ago
The same php+jquery+ajax+plain css stack that used to work 7 years ago, would likely still work today. Thats a great departure from famous, glamorous new orchestration/styling/components/web standards that are adopted before they are ready and are obsolete in 18 months after deployment.
dvfjsdhgfv 8y ago
This is a common theme on HN but it's actually quite simple: 1. If you want to get hired, you need to know the tools in fashion now. It's always been like that but recently these proliferated so much it's quite difficult to catch up even in the market you specialize in. 2. If you want to build a successful product, you need to be smart and use what you know in the best way, and only spent your time to learn something new if it's really necessary. That's why some of the biggest sites in the world were written in PHP, Photoshop was originally written in Pascal, Minecraft in Java etc. There is much more to say about it but the essence is that.
- azangru 8y ago
  > If you want to get hired, you need to know the tools in fashion now. I think it's an unfair over-generalization. There are quite a few places that started building their tech a fair number of years ago, and have accumulated quite a legacy that needs to be maintained. They would probably want someone with decent knowledge of those dated technologies. The question is, given the choice, would you, personally, want to work on a legacy system, or would you rather prefer to work with something new and shiny. I think the answer will overwhelmingly be the latter. I personally am sure I would pick new and shiny, because it is generally much more pleasant and satisfying to work with than old technologies.
  - mschuster91 8y ago
    > I personally am sure I would pick new and shiny, because it is generally much more pleasant and satisfying to work with than old technologies. I prefer not to be on the bleeding edge of stuff, especially not in the JS world - got bitten too often by incomplete, missing or flat out wrong official documentation, horrenduous bugs, incompatibilities and sudden breaking changes all over the place. Side note to all shiny tool vendors out there, if you want people to try out your stuff, provide usable documentation and don't force your users to copy-and-paste from StackOverflow...
    - azangru 8y ago
      I am struggling to think of something that would be both hyped (therefore, popular, and widely used), and at the same time poorly documented. React has a fantastic documentation, but React is hardly bleeding edge anymore. Webpack used to be bad with documentation, but has dramatically improved in the recent couple of years. Vue is said to have documentation that is on par with React’s. Perhaps for RxJS documentation is still a pain point, but other than that... can't really say I have been burnt by documentation.
martin_drapeau 8y ago
The beauty of front-end development is that you can USE WHATEVER YOU WANT. The end-user really doesn't care. As long as the UI is good. The browser really won't care either. It will interpret that JavaScript whatever framework or library you've used. When it comes to collaborating with fellow developers, its another story. We switched to React at Amilia because its easier to hire developers. For personal projects jQuery, Bootstrap and Backbone are still my tools of choice.
- JustSomeNobody 8y ago
  I bet if I searched HN I’d get more hits for “just use react” than I would for “use whatever you want.”
root_axis 8y ago
Exactly! I don't understand all the complaining about the complexity of the front-end; if you don't like modern front-end tools you're not obligated to use them, all the old tools work just fine. Just because someone releases their own work for free on the internet doesn't mean you're obligated to use it. If you don't understand what problems a particular tool solves, you definitely shouldn't be using it. Stick to what you know or deal with the learning curve. It's literally a software engineer's job to figure out the best tools to solve the problem at the lowest cost, if you're just picking the most popular tools because they're popular then you are to blame. I don't buy the employment gripe either. If you don't like working with the tools that are popular in front-end development then it's time to pick a different job. There's plenty of work in java, ruby, c#, swift, go, kotlin, cpp etc, and a bunch of legacy PHP/JS systems that function in completely different paradigms and ecosystems. If you're fresh out of school and JS is the only language you know and you're frustrated by all the complexity, that's not anyone's fault except your own lack of experience. Stop expecting everyone to stop working on free tools because they confuse you. /rant off
- noitsnot 8y ago
  It's not that simple. If you don't like them, you have no choice. Every company from large to small has jumped on the bandwagon. Maybe I'm wrong, but companies want frontend dev with angular and react, but the complexity is at a point where you need a back-end who understands data types and CS. So, you're essentially taking a discounted rate or front-end pay while providing back-end. A "Full stack" dev or worse, a Graphic Designer who is expected to do front-end.
  - root_axis 8y ago
    > It's not that simple. If you don't like them, you have no choice. I already addressed that. If you don't like the contemporary front-end tools there are plenty of other programming domains to work in that use other languages and tools. There are also many huge legacy JS systems (especially in the corporate world) that need traditional JS skillsets. > but the complexity is at a point where you need a back-end who understands data types and CS I would argue that front-end developers should already be expected to understand "data types and CS" otherwise they should be earning a designer salary instead of an engineer salary (no disrespect to designers, what they do is also complex, but engineers are paid more on average). > A "Full stack" dev. I disagree. A full stack dev, in addition to front-end, would be expected to also understand how to wire-up back-end services and databases and create abstractions that make this data available for the front-end or other back-end consumers. There aren't really any positions with the exclusive front-end title that also expects any of that. Being able to configure webpack or babel is not "back end" or "full stack", webpack is just a pre-processing tool, not unlike any of the other myriad front-end tools that have existed for years (e.g. sass, less, haml, compass etc)
deleted 8y ago
[deleted]
tambourine_man 8y ago
I love PHP and jQuery and use it whenever possible. I really tried to find a reason to use Backbone, Angular, React over the years. Vue is the only one that seems appealing but still, not terribly so. editing PHP with Vim in production via a tmux session Replace production with development instance and you’re good to go.
- AdrianB1 8y ago
  I did look at these from time to time, I find Vue as useful to simplify UI logic without bringing a huge complexity or learning curve. It is just a personal opinion, but I tend to see these as options you have, not mandatory to use if you don't have a need for it. Having more options can be better, the huge downside is the fragmentation. The classic problem is: do you prefer a single programming language, a dozen or a thousand? I would go for a dozen, one is not flexible enough, a thousand is too fragmented for most to be worth considering.
emersonrsantos 8y ago
Take serverless, for example. It’s just CGI that scales better. People will see this simple, but powerful approach, and will hopefully return to a transactional webpage programming style (as the Web was intended to be). All the monoliths will be out of fashion again.
- kokokokoko 8y ago
  I love to joke that cloud functions are just PHP shared hosts that support node, go, etc as opposed to PHP, Perl etc. It is a bit of an exaggeration, of course, but fun to joke about. I agree completely. The tranactional nature of that shared hosting era made hosting an application or website orders of magnitude cheaper and easier and led to an absolute boom of open source solutions like Wordpress. I hope to see some standardization across the serverless ecosystem to allow a similar situation as opposed to the lock-in approach taken by AWS and other cloud platforms.
- InGodsName 8y ago
  In CGI ecosystem there was no kinesis, cloudwatch, Dynamodb. Considering serverless lambda i isolation isn't a worthy comparison.
stickfigure 8y ago
I run a small SaaS business in a niche market. The whole company is two engineers; our UI is a SPA built with react and material design. We have one direct competitor, who launched around the same time we did. They have at least 6 engineers (plus support staff); they built a traditional webapp with some jquery. We get a fair number of their users. They all gush about how easy our system is to use and how much better the UX is. Some of this is the different conceptual approach we took to the problem, but we couldn't have pulled that off without the interactivity that a SPA gave us. Modern web dev tools significantly raise the bar for customer experience. Sure, you can build a PHP app with some jquery and form posts. If you have no competition, you may do alright. But customers notice UX, and you should be afraid of upstarts who do chase the "modern ecosystem".
- chx 8y ago
  UX design and the technology used to implement it have nothing to do with each other. Absolutely none.
  - stickfigure 8y ago
    You clearly weren't trying to build rich UIs in the 90s and 2000s with the technology available then.
    - cat199 8y ago
      This isn't a fair comparison because the 'base' underlying HTML/CSS/JS language is much more standardized and feature rich - tooling + ecosystem on top of that is just that. i'm personally a pragmatist who likes systems thinking - a hand coded form + CGI still works just as well as a full featured SPA to 'correctly fulfill' requirements, the variable in question is the requirements.
    - marpstar 8y ago
      React and Material UI are still just HTML, CSS, and JS.
      - 8y ago
iseeyoubydesign 8y ago
>Let’s use whatever we’re productive with. I have no idea how containers work and don’t care to find out until I feel the need. Somebody might feel that way about React or webpack and that’s totally healthy too. I really dont mind this opinion as a hobbyist but as a professional its lazy and arrogant. I get the tech fatiguee of learning the 5th MVC or frontend framework. But that what differentiates you from a good and great professional. Also learning new styles and tools gives you a robust view of how software is created. Its just a good practice that a profession engineer,one that cares about being productive will not shun. Dont be lazy or enjoy being stuck in "your way". I think this keeps people from being hired not because of the actually lack of skill breadth but because of the attitude behind it.
samfisher83 8y ago
https://w3techs.com/technologies/details/pl-php/all/all https://w3techs.com/technologies/details/pl-php/all/all Php still runs a majority of the web.
AdrianB1 8y ago
Not a developer, but a low level IT manager in a top 50 Fortune 500 company: for my area I chose to use almost plain PHP and jQuery and a few tools for our internal use apps, not the latest, shiniest tech available for 3 days. Finding developers with real expertise, being able to support the applications 5 or more years, having stuff that simply works is much more important than using the obscure or temporary in fashion technology of the day. Yes, there are so many options and there are so few that meet the criteria...
- akie 8y ago
  I’m sorry, but you’re 5 to 10 years behind the times, and I say that as a non-bandwagon-jumping old guy. Plain PHP these days is almost always a mistake, there are new (and proven, stable) tools that provide significant benefits without any real downsides.
  - AdrianB1 8y ago
    Can you please provide a few examples? Just curious how it can be simpler and cheaper to build and maintain when performance is more than enough, usability is great and the end results are exceeding all expectations. Other than being out of fashion, what is wrong with things that simply work?
    - JustSomeNobody 8y ago
      Because it’s not about the end product. It’s about developers. It’s resume driven development. Sadly, devs have to do this otherwise other dev managers won’t hire them for being out of date. It’s a vicious, pathetic cycle.
    - andrewmackrodt 8y ago
      I think plain PHP may have been taken to mean you're using an in house framework without using a package manager such as composer. In this case it's definitely more expensive to roll your own solution, especially when it comes to maintenance and onboarding.
jeklj 8y ago
Sure PHP+Ajax still works, knock yourself out using that approach if you want. I won’t want to maintain your code, but feel free. While I don’t disagree with the general notion that old stuff still works and new stuff is not necessarily better, this notion is incredibly well-worn around these parts. It really would be nice if people stopped driving it into the ground pretending it’s an interesting or original or contrarian point. What I do find interesting is one of the replies by someone saying they quit webdev back in the PHP+ajax days, precisely because they found that approach so much less simple than it is often claimed to be. That’s an actual interesting point! But we don’t want to talk about that, we want to talk about “JS devs love everything shiny that came out 3 days ago.”
Myrth 8y ago
The "My way is better than yours" insecurity projection

79 points by seapunk 8y ago

cobythedog 8y ago

I feel like I am missing something. Is this just a blog-response to a comment on HN?

moreira 8y ago
It's a series-of-tweets response to a comment, wrapped up in a blogpost-like format. ... Yeah.
giancarlostoro 8y ago
The tweet is at the top, but yeah it reads a little weird without the context that it's a bunch of tweets. Source: https://twitter.com/dan_abramov/status/1078388060696576001 https://twitter.com/dan_abramov/status/1078388060696576001

kbenson 8y ago

I would like to point out a middle ground, where I currently reside. Back-end in whatever you want (Perl + Mojolicious for me), and a front end using one of the major frameworks (Vue for me), but without even the need to managing it all with node and NPM (you can still just use script tags, it's not that hard if you don't go crazy with inclusions). Serve pages as simple templates, with maybe some embedded JSON to cut out the initial AJAX request, and now you're playing to the strengths of each part of the stack. You have a back-end that you're comfortable with and possibly have your own library of utilities for, you have a front-end that leverages all the power the browser brings to the table, and you aren't mixing front-end jQuery style actions with back-end templating and the pain that eventually results in.

giancarlostoro 8y ago
> with maybe some embedded JSON to cut out the initial AJAX request That's the only hackish portion out of there, otherwise I'd agree. I rather get back what I expect from an endpoint not some mixture of things.
- kbenson 8y ago
  Well, if you're asking the endpoint for an HTML representation of something, and it responds with template portions and rules for combining them based on data (React,Vue), doesn't it make sense to respond with all the date needed to actually build it right then and there? If someone requests /users.json I return JSON. If someone requests /users.html I return a document with rules in JS for how to build the HTML based on the data (Vue) and the JSON to build it with. In both cases the JSON is the important part, the Vue stuff included in the HTML version is just a transform on that data to be applied by the client. In that respect, I think not including the desired JSON would by hacky, requiring a separate request for the actual data you requested initially.
azangru 8y ago
> a front end using one of the major frameworks (Vue for me), but without even the need to managing it all with node and NPM This sounds like such an arbitrarily painful limitation I couldn't resist asking: why? As far as I heard, package managers have been regarded by every language as a blessing. Ruby has its Bundler; Python has its pip; PHP has its Composer (and I heard PHP programmers joke that they feel like grown-ups now, when they have modern tools). Why would you deliberately exclude Node, NPM, and the whole ecosystem that it brings to the table?
- kbenson 8y ago
  Because I'm literally using Vue, Axios, a polyfill, and Bootstrap-Vue. Two CSS link tags, and four script tags. Currently for external resources, but trivially brought locally. It's an internal web-app, so it's not like minification is even required, much less bundling. No Javascript is used on the back-end currently. To use NPM/yarn/etc, I would have to first install Node, and then configure it to build my stack. At some point if I pull in a bunch of requirements, maybe that's worthwhile, but right now, it's actually a fair amount of work for dubious return given my current needs.
  - azangru 8y ago
    > I would have to first install Node You mean, locally, on your machine? But it's not a big deal. Not even a small deal. It's, like, not a deal at all. But I get your point. I thought you were advocating a general approach, but instead you were describing your specific setup.
    - kbenson 8y ago
      > You mean, locally, on your machine? Well, in this case development is done through Vim on the remote server, first in a dev environment branch, and then pulled from production. It would require installing the tool chain on the server, which is an artifact of my development process, but nevertheless should require consideration in my case. But yeah, I'm just describing my setup, and the ease of which it allows getting started and productive. I'm wasn't really advocating for or against using a build process for the front end in general, just noting my current process. I imagine if I was using a lot of modules in my front-end, I would see the benefit of putting more tooling in place to maintain and manage it fairly quickly.
ashton314 8y ago
> Perl, Mojolicious, Vue That's a lovely stack you got there. I'm a Perl guy (sometimes) myself, and I hated all the bloat of the JavaScript tooling. I recently found Vue and I fell in love with how light-weight it is.

jcroll 8y ago

Whatever works but a lot of these modern tools were designed with good reasons and good intentions. Build your mvp with PHP + Ajax, if it's successful tho might not be long till you're hitting a wall and looking for more robust solutions

wolco 8y ago
PHP is modern and if you wanted to, you could use the latest laravel framework or microframework with whatever bleeding edge version. If you have a small website plain php/jquery will be faster and simplier to work with.

giancarlostoro 8y ago

Use what you're best at, and if you're paid to use something, use it. If you don't like what you're using at work, take your time to find a new job opportunity. I feel like SPA's are overrated they take away performance and stability from standard HTML websites with some AJAX capabilities thrown in. When I first heard of a SPA it sounded perfect: you download all the HTML you'll ever need once, and load content to the appropriate DIVs accordingly, but now you gotta take a hike and basically do more work to show a button, or a text box, or whatever. I mean no disrespect to people who love SPA web dev, all power to you, but unless I'm paid a lot more, or I'm working on some multimedia / social media type of site, I don't see the point. Sometimes SPA's I see are done poorly which is another pet peeve.

scarecrowbob 8y ago
I'm not totally sure about the context for the OP, but just recently there are a lot of folks doing low-end PHP dev work for WordPress, and many of them are now having to learn React because WordPress has changed its backend editor to a system that is based around React. Personally, I think that this is a good choice-- the editor system in that CMS is a very good use case for complex JS technologies. But at the same time, there are a whole lot of of folks who have been doing a lot of work with PHP who didn't want to learn that toolchain. In that context, it's a little complex: we have a whole ecosystem of businesses and developers and software tooling that is being pushed over by some core changes. I'd bet that there are going to be a lot of frustrated low-end PHP devs dragged into learning modern-ish JS tooling.
- giancarlostoro 8y ago
  Interesting, I knew they had a new editor, since I have a few WordPress blogs, but I only use them, I don't code anything with them, so I hadn't considered how they're rewritten. I don't mind when SPA is used properly, and in this case it only affects one specific use case which makes a lot of sense.
- arkh 8y ago
  > modern-ish JS tooling This need a lot more scary quotes around modern and tooling. The JS "ecosystem" is a cancer: nowadays when you want to do some front-end work with some CSS you usually end with an install of node and npm/webpack/the-shit-du-jour, half of them crying about incompatibilities and how you should use the shit-du-lendemain instead to compile you don't really don't know what, it still takes 20mn to see the result. All you wanted was to edit some CSS. And surprise: now half of your other projects won't build anymore because you had to install npm-1.911-HELP-ME-DAD and the option to not install globally changed from -not-everywhere to --just-a-local-beer.

altmind 8y ago

The same php+jquery+ajax+plain css stack that used to work 7 years ago, would likely still work today. Thats a great departure from famous, glamorous new orchestration/styling/components/web standards that are adopted before they are ready and are obsolete in 18 months after deployment.

dvfjsdhgfv 8y ago

This is a common theme on HN but it's actually quite simple: 1. If you want to get hired, you need to know the tools in fashion now. It's always been like that but recently these proliferated so much it's quite difficult to catch up even in the market you specialize in. 2. If you want to build a successful product, you need to be smart and use what you know in the best way, and only spent your time to learn something new if it's really necessary. That's why some of the biggest sites in the world were written in PHP, Photoshop was originally written in Pascal, Minecraft in Java etc. There is much more to say about it but the essence is that.

azangru 8y ago
> If you want to get hired, you need to know the tools in fashion now. I think it's an unfair over-generalization. There are quite a few places that started building their tech a fair number of years ago, and have accumulated quite a legacy that needs to be maintained. They would probably want someone with decent knowledge of those dated technologies. The question is, given the choice, would you, personally, want to work on a legacy system, or would you rather prefer to work with something new and shiny. I think the answer will overwhelmingly be the latter. I personally am sure I would pick new and shiny, because it is generally much more pleasant and satisfying to work with than old technologies.
- mschuster91 8y ago
  > I personally am sure I would pick new and shiny, because it is generally much more pleasant and satisfying to work with than old technologies. I prefer not to be on the bleeding edge of stuff, especially not in the JS world - got bitten too often by incomplete, missing or flat out wrong official documentation, horrenduous bugs, incompatibilities and sudden breaking changes all over the place. Side note to all shiny tool vendors out there, if you want people to try out your stuff, provide usable documentation and don't force your users to copy-and-paste from StackOverflow...
  - azangru 8y ago
    I am struggling to think of something that would be both hyped (therefore, popular, and widely used), and at the same time poorly documented. React has a fantastic documentation, but React is hardly bleeding edge anymore. Webpack used to be bad with documentation, but has dramatically improved in the recent couple of years. Vue is said to have documentation that is on par with React’s. Perhaps for RxJS documentation is still a pain point, but other than that... can't really say I have been burnt by documentation.

martin_drapeau 8y ago

The beauty of front-end development is that you can USE WHATEVER YOU WANT. The end-user really doesn't care. As long as the UI is good. The browser really won't care either. It will interpret that JavaScript whatever framework or library you've used. When it comes to collaborating with fellow developers, its another story. We switched to React at Amilia because its easier to hire developers. For personal projects jQuery, Bootstrap and Backbone are still my tools of choice.

JustSomeNobody 8y ago
I bet if I searched HN I’d get more hits for “just use react” than I would for “use whatever you want.”

root_axis 8y ago

Exactly! I don't understand all the complaining about the complexity of the front-end; if you don't like modern front-end tools you're not obligated to use them, all the old tools work just fine. Just because someone releases their own work for free on the internet doesn't mean you're obligated to use it. If you don't understand what problems a particular tool solves, you definitely shouldn't be using it. Stick to what you know or deal with the learning curve. It's literally a software engineer's job to figure out the best tools to solve the problem at the lowest cost, if you're just picking the most popular tools because they're popular then you are to blame. I don't buy the employment gripe either. If you don't like working with the tools that are popular in front-end development then it's time to pick a different job. There's plenty of work in java, ruby, c#, swift, go, kotlin, cpp etc, and a bunch of legacy PHP/JS systems that function in completely different paradigms and ecosystems. If you're fresh out of school and JS is the only language you know and you're frustrated by all the complexity, that's not anyone's fault except your own lack of experience. Stop expecting everyone to stop working on free tools because they confuse you. /rant off

noitsnot 8y ago
It's not that simple. If you don't like them, you have no choice. Every company from large to small has jumped on the bandwagon. Maybe I'm wrong, but companies want frontend dev with angular and react, but the complexity is at a point where you need a back-end who understands data types and CS. So, you're essentially taking a discounted rate or front-end pay while providing back-end. A "Full stack" dev or worse, a Graphic Designer who is expected to do front-end.
- root_axis 8y ago
  > It's not that simple. If you don't like them, you have no choice. I already addressed that. If you don't like the contemporary front-end tools there are plenty of other programming domains to work in that use other languages and tools. There are also many huge legacy JS systems (especially in the corporate world) that need traditional JS skillsets. > but the complexity is at a point where you need a back-end who understands data types and CS I would argue that front-end developers should already be expected to understand "data types and CS" otherwise they should be earning a designer salary instead of an engineer salary (no disrespect to designers, what they do is also complex, but engineers are paid more on average). > A "Full stack" dev. I disagree. A full stack dev, in addition to front-end, would be expected to also understand how to wire-up back-end services and databases and create abstractions that make this data available for the front-end or other back-end consumers. There aren't really any positions with the exclusive front-end title that also expects any of that. Being able to configure webpack or babel is not "back end" or "full stack", webpack is just a pre-processing tool, not unlike any of the other myriad front-end tools that have existed for years (e.g. sass, less, haml, compass etc)

deleted 8y ago

[deleted]

tambourine_man 8y ago

I love PHP and jQuery and use it whenever possible. I really tried to find a reason to use Backbone, Angular, React over the years. Vue is the only one that seems appealing but still, not terribly so. editing PHP with Vim in production via a tmux session Replace production with development instance and you’re good to go.

AdrianB1 8y ago
I did look at these from time to time, I find Vue as useful to simplify UI logic without bringing a huge complexity or learning curve. It is just a personal opinion, but I tend to see these as options you have, not mandatory to use if you don't have a need for it. Having more options can be better, the huge downside is the fragmentation. The classic problem is: do you prefer a single programming language, a dozen or a thousand? I would go for a dozen, one is not flexible enough, a thousand is too fragmented for most to be worth considering.

emersonrsantos 8y ago

Take serverless, for example. It’s just CGI that scales better. People will see this simple, but powerful approach, and will hopefully return to a transactional webpage programming style (as the Web was intended to be). All the monoliths will be out of fashion again.

kokokokoko 8y ago
I love to joke that cloud functions are just PHP shared hosts that support node, go, etc as opposed to PHP, Perl etc. It is a bit of an exaggeration, of course, but fun to joke about. I agree completely. The tranactional nature of that shared hosting era made hosting an application or website orders of magnitude cheaper and easier and led to an absolute boom of open source solutions like Wordpress. I hope to see some standardization across the serverless ecosystem to allow a similar situation as opposed to the lock-in approach taken by AWS and other cloud platforms.
InGodsName 8y ago
In CGI ecosystem there was no kinesis, cloudwatch, Dynamodb. Considering serverless lambda i isolation isn't a worthy comparison.

stickfigure 8y ago

I run a small SaaS business in a niche market. The whole company is two engineers; our UI is a SPA built with react and material design. We have one direct competitor, who launched around the same time we did. They have at least 6 engineers (plus support staff); they built a traditional webapp with some jquery. We get a fair number of their users. They all gush about how easy our system is to use and how much better the UX is. Some of this is the different conceptual approach we took to the problem, but we couldn't have pulled that off without the interactivity that a SPA gave us. Modern web dev tools significantly raise the bar for customer experience. Sure, you can build a PHP app with some jquery and form posts. If you have no competition, you may do alright. But customers notice UX, and you should be afraid of upstarts who do chase the "modern ecosystem".

chx 8y ago
UX design and the technology used to implement it have nothing to do with each other. Absolutely none.
- stickfigure 8y ago
  You clearly weren't trying to build rich UIs in the 90s and 2000s with the technology available then.
  - cat199 8y ago
    This isn't a fair comparison because the 'base' underlying HTML/CSS/JS language is much more standardized and feature rich - tooling + ecosystem on top of that is just that. i'm personally a pragmatist who likes systems thinking - a hand coded form + CGI still works just as well as a full featured SPA to 'correctly fulfill' requirements, the variable in question is the requirements.
  - marpstar 8y ago
    React and Material UI are still just HTML, CSS, and JS.
    - 8y ago

iseeyoubydesign 8y ago

>Let’s use whatever we’re productive with. I have no idea how containers work and don’t care to find out until I feel the need. Somebody might feel that way about React or webpack and that’s totally healthy too. I really dont mind this opinion as a hobbyist but as a professional its lazy and arrogant. I get the tech fatiguee of learning the 5th MVC or frontend framework. But that what differentiates you from a good and great professional. Also learning new styles and tools gives you a robust view of how software is created. Its just a good practice that a profession engineer,one that cares about being productive will not shun. Dont be lazy or enjoy being stuck in "your way". I think this keeps people from being hired not because of the actually lack of skill breadth but because of the attitude behind it.

samfisher83 8y ago

https://w3techs.com/technologies/details/pl-php/all/all https://w3techs.com/technologies/details/pl-php/all/all Php still runs a majority of the web.

AdrianB1 8y ago

Not a developer, but a low level IT manager in a top 50 Fortune 500 company: for my area I chose to use almost plain PHP and jQuery and a few tools for our internal use apps, not the latest, shiniest tech available for 3 days. Finding developers with real expertise, being able to support the applications 5 or more years, having stuff that simply works is much more important than using the obscure or temporary in fashion technology of the day. Yes, there are so many options and there are so few that meet the criteria...

akie 8y ago
I’m sorry, but you’re 5 to 10 years behind the times, and I say that as a non-bandwagon-jumping old guy. Plain PHP these days is almost always a mistake, there are new (and proven, stable) tools that provide significant benefits without any real downsides.
- AdrianB1 8y ago
  Can you please provide a few examples? Just curious how it can be simpler and cheaper to build and maintain when performance is more than enough, usability is great and the end results are exceeding all expectations. Other than being out of fashion, what is wrong with things that simply work?
  - JustSomeNobody 8y ago
    Because it’s not about the end product. It’s about developers. It’s resume driven development. Sadly, devs have to do this otherwise other dev managers won’t hire them for being out of date. It’s a vicious, pathetic cycle.
  - andrewmackrodt 8y ago
    I think plain PHP may have been taken to mean you're using an in house framework without using a package manager such as composer. In this case it's definitely more expensive to roll your own solution, especially when it comes to maintenance and onboarding.

jeklj 8y ago

Sure PHP+Ajax still works, knock yourself out using that approach if you want. I won’t want to maintain your code, but feel free. While I don’t disagree with the general notion that old stuff still works and new stuff is not necessarily better, this notion is incredibly well-worn around these parts. It really would be nice if people stopped driving it into the ground pretending it’s an interesting or original or contrarian point. What I do find interesting is one of the replies by someone saying they quit webdev back in the PHP+ajax days, precisely because they found that approach so much less simple than it is often claimed to be. That’s an actual interesting point! But we don’t want to talk about that, we want to talk about “JS devs love everything shiny that came out 3 days ago.”

Myrth 8y ago

The "My way is better than yours" insecurity projection