9 ms·

I wonder how many are like me (old school? Just old??) and eschew platforms and libraries and roll my own most of the time, because most of the time, the needs

by DougN7 10y ago

I wonder how many are like me (old school? Just old??) and eschew platforms and libraries and roll my own most of the time, because most of the time, the needs are simple, and it's quicker to pound something out rather than learn and use Yet Another Framework. Though using jquery is nice sometimes...

johnloeber 10y ago
That's the approach I took to hand-rolling my personal website. All I care about is delivering my content reasonably well -- the elegance or modernity of the underlying engineering seems irrelevant. (Not to mention that this minimizes website bloat...)
pavlov 10y ago
I do that. Web dev is not my main focus, but I have to deal with it all the time. I try to attack the problems with an initial prototype that's a combination of plain HTML+JS and Node.js. Instead of a database, I tend to reuse a simple Javascript class I wrote a couple of years back that provides a minimalist layer of persistence for collections using an append-only file. (It's really just a single file I copy to any new projects when it's time to store something.) Over 90% of the time that prototype turns out to be good enough, either because the problem is abandoned or remains at a level where a rewrite isn't worth it. So far I haven't regretted not investing time into learning Framework X every few years... Although I'm probably going to start deploying React instead of plain JS soon. The library is very useful for real-world UI problems, even though it's surrounded by a deafening amount of toolchain fetishism which tends to cloud React's fundamental simplicity. (I'm 36, started writing C in 1990 and HTML in 1995, so I feel somewhat old in this industry already.)
- msane 10y ago
  I recommend avoiding React. I have never seen an ecosystem so bogged down at every turn. It also has a bad zealot problem, where Facebook has cleverly brought a lot of people to it who haven't seen anything else and are convinced it is the bee's knees. > The library is very useful for (?) UI problems... Components are good. But they didn't come from React and React isn't the only place to get them. Angular 1/2, Polymer, Ember are great in comparison. And so much more simple. React's position on simplicity is that the demos on the site are all 15 lines so that means it's simple right? You can't say it's complicated because it's 15 lines, see? It's "easy to reason about", i.e., "you're not smart if you don't get it". Once you see the toolchain and ecosystem you will glimpse the price of those 15 lines. > ...toolchain fetishism which tends to cloud React's fundamental simplicity This is a very real thing. People who work in React spend way more time fixing toolchain stuff and trying to mix 10 artisanal-crafted "easy to reason about" libraries in order to accomplish tasks which are either solved or not even issues in other component frameworks.
  - microcolonel 10y ago
    I frankly don't see how you could come to the conclusion that Angular 2 components are simpler than React components. I mean, in React, a component can be as simple as const MyComponent = () => <span> some markup nonsense </span>;
    - msane 10y ago
      Yup that's the argument mentioned: React is "simpler", "anyone can see"... Brevity isn't simplicity. The simplicity is being easier to install, build, read about, debug, consume APIs with, send data between, talk about to other developers... and yes, "reason" about. myMod.component('Foo', { template: '<h1>{{$and.better.templating}} {{see()}}</h1>', controller: function() { var and = {this_one: 'does_stuff'}; } });
      - thegayngler 10y ago
        This is not easier to reason about than returning jsx IMO... It's only 1 of the ways to build an angular 2 component. The website tutorial is using decorator syntax. Typescript Angular 2 documentation. What's wrong with just learning JavaScript and less Angular specific syntax and tooling. Maybe I'm wrong but I feel like Angular likes to force projects to become big monoliths where people who don't understand the problem being solved are trying to architect a solution for all of the problems. React does have jsx shock and JavaScript tooling fatigue. However, now that React is mature JavaScript tooling decision fatigue should be less of an issue. You aren't relying on one company to solve problems. You have a community solving problems for themselves. As they need it they can add it or take it away.
      - warfangle 10y ago
        Why aren't you just using an interpolated string?
  - Silhouette 10y ago
    I recommend avoiding React. I have never seen an ecosystem so bogged down at every turn. It's perfectly possible to just use React on its own, without getting bogged down with all the other buzzword-of-the-week stuff around it. React itself has been reasonably stable for a long time in Web terms. It is much more tightly scoped and smaller in its interface than most JS frameworks. There are a couple of major design trade-offs, which often seem to get overlooked in React advocacy, but if you have a bit of experience using it and understand the practical pros and cons then you can quickly decide whether the balance is favourable for some new project. People who work in React spend way more time fixing toolchain stuff and trying to mix 10 artisanal-crafted "easy to reason about" libraries in order to accomplish tasks which are either solved or not even issues in other component frameworks. Some people who work with React might. Plenty of others don't.
- rco8786 10y ago
  I hope your not pushing that to any meaningful production environment
  - JustSomeNobody 10y ago
    Why? Define "meaningful".
- grumblestumble 10y ago
  "Over 90% of the time that prototype turns out to be good enough, either because the problem is abandoned or remains at a level where a rewrite isn't worth it." You might want to spend some introspection time on that statement.
  - pavlov 10y ago
    What do you mean by that?
fenomas 10y ago
> eschew platforms and libraries and roll my own most of the time That's what nearly everybody does, when they're one person hacking on a one-off project. I like to hate on Big Web Frameworks as much as anyone, but it should be understood that their value isn't replacing your hand-rolled code, their value is to let big 20-person projects avoid having 20 different flavors of hand-rolled code.
- pavlov 10y ago
  Thing is, complex frameworks like Angular tend to allow for 20 different ways to accomplish the same thing, so they don't really solve the underlying problem: team members still need to agree on a common approach and a shared set of idioms and coding styles. There is a difference though. When there's a big framework involved, discussion will tend towards "Is this the right way to do X in Angular?" rather than "How do we want to solve X?". That may be good or bad, depending on whether you want to build your career around being an "Angular expert" (or a "Rails expert" or "SAP expert" or "COBOL/IMS expert" or any other kind of framework expert).
  - buckbova 10y ago
    I picked up Angular quickly, insisted everyone in my group follow this style guide. https://github.com/johnpapa/angular-styleguide https://github.com/johnpapa/angular-styleguide We didn't need an expert.
    - jasonm23 10y ago
      Seems you were lucky that the expert you didn't need had written up a style guide.
      - buckbova 10y ago
        Definitely. We live in wonderful times.
    - thegayngler 10y ago
      I don't like Angular 1.xxx that much because in Angular 1.xxx building simple stuff in JavaScript is a no no. Angular doesn't play nicely with JavaScript. Instead you have to do Angularjs way and write the Angular specific code in your 50 Angular specific HTML attributes. Performance of data intensive apps is particularly lousy in Angular. In my opinion it's a framework written for people who like complexity for complexity's sake. I don't want to be hunting all over my code base just to figure out what is happening in a controller or component. JPs styleguide is awesome!
hajile 10y ago
It's not so much a change in technology as it is a shift in focus. If you or your company needs a basic website, then wordpress will almost always take you as far as you need to go. There's not a huge need for devs and nobody who's good at the web wants to be there because it's a race to the bottom financially. That part of the web (the overwhelming majority I might add) is pretty stagnant with few real changes or advancements having happened in the past decade. Apps failed in that nobody wants to install your app on their device unless it's a game, a free utility, or one of a few popular apps made by large companies. WebOS got the idea of web technologies right, but the devices were too limited. Today, the idea of a web app that runs everywhere is very appealing and much more accessible to clients. All the new frameworks are really targeting this kind of use. Pounding the square that is web apps through the round hole that is the browser is hard, but still better than the alternatives. If you're making a website, jQuery and simple JS is usually all you need. If you're making a web app with complex data and complex UI, you need a framework to keep things sane.
- blub 10y ago
  Web app with complex data = website that can be done very well with html, css and a server-side language. It's only the complex UI which requires JS frameworks and libraries, but building such a UI is already a losing proposition and the main reason why web programming is getting "unnecessarily complicated". Web developers think that web apps can compete with native applications - they still can't and in the process of trying to get them there, they turned the process of building websites into a mess.
  - onion2k 10y ago
    Web app with complex data = website that can be done very well with html, css and a server-side language. Only if you make a baseless assumption about the user's internet connection. Someone whose connection drops out regularly, or who faces periods without a connection at all, is going to hate your server-side app compared to my offline-first progressive web app that they can have cached on their device and that syncs their changes using pouchdb/couchdb. My app will have a ton of JS that yours doesn't, but that extra code makes it work when they're not online. That's a huge advantage. Not all progress is designed for added shininess. Some of the changes that are happening are designed to fix real problems that people face.
notliketherest 10y ago
wow this attitude is so sad! React + Redux - changed my whole outlook on web development and it's actually a joy again. Take a little bit of time, read, learn, figure out a simple webpack script, and you're gonna love life.
kalleboo 10y ago
Most of the web stuff I have to work on is developed once, and then maintained rarely (once a year or so). It's not the kind of project that has continuous development. So whenever I've used a framework or SDK, when it comes time to add a small feature or tweak, I spend more time bringing the project up to date with the latest version of the framework or SDK than I do implementing the feature. Literally every time I update one of our sites using a Facebook SDK, they've changed around how the whole SDK is designed and I have to rewrite basic things like session management.
- polishninja 10y ago
  I've run into this issue multiple times as well.
blub 10y ago
I think there's a lot of social pressure from rockstar web developers to build and use JS libraries and frameworks. Let's face it, classic front-end web development works fine and is well understood. Doesn't get you into conferences or help you sell courses. So we get the web of today, piles of Javascript and unnecessary complexity all wrapped together with ads and tracking. And excuses about how today's customers expect an app-like experience.
- jasonthevillain 10y ago
  > And excuses about how today's customers expect an app-like experience Yes. If anyone has evidence of this I'd love to see it.
pbreit 10y ago
I'm still sort of a newbie but I have found it much much easier for me to quickly build my projects on the very very easy to use Web2py Python framework. The things I like are: defining my DB structure in simple code, no routing (routing is implied by file & function names), Python, HTML views with simple embedded code (including full Python if need/want).

by DougN7 10y ago

johnloeber 10y ago

That's the approach I took to hand-rolling my personal website. All I care about is delivering my content reasonably well -- the elegance or modernity of the underlying engineering seems irrelevant. (Not to mention that this minimizes website bloat...)

pavlov 10y ago

I do that. Web dev is not my main focus, but I have to deal with it all the time. I try to attack the problems with an initial prototype that's a combination of plain HTML+JS and Node.js. Instead of a database, I tend to reuse a simple Javascript class I wrote a couple of years back that provides a minimalist layer of persistence for collections using an append-only file. (It's really just a single file I copy to any new projects when it's time to store something.) Over 90% of the time that prototype turns out to be good enough, either because the problem is abandoned or remains at a level where a rewrite isn't worth it. So far I haven't regretted not investing time into learning Framework X every few years... Although I'm probably going to start deploying React instead of plain JS soon. The library is very useful for real-world UI problems, even though it's surrounded by a deafening amount of toolchain fetishism which tends to cloud React's fundamental simplicity. (I'm 36, started writing C in 1990 and HTML in 1995, so I feel somewhat old in this industry already.)

msane 10y ago
I recommend avoiding React. I have never seen an ecosystem so bogged down at every turn. It also has a bad zealot problem, where Facebook has cleverly brought a lot of people to it who haven't seen anything else and are convinced it is the bee's knees. > The library is very useful for (?) UI problems... Components are good. But they didn't come from React and React isn't the only place to get them. Angular 1/2, Polymer, Ember are great in comparison. And so much more simple. React's position on simplicity is that the demos on the site are all 15 lines so that means it's simple right? You can't say it's complicated because it's 15 lines, see? It's "easy to reason about", i.e., "you're not smart if you don't get it". Once you see the toolchain and ecosystem you will glimpse the price of those 15 lines. > ...toolchain fetishism which tends to cloud React's fundamental simplicity This is a very real thing. People who work in React spend way more time fixing toolchain stuff and trying to mix 10 artisanal-crafted "easy to reason about" libraries in order to accomplish tasks which are either solved or not even issues in other component frameworks.
- microcolonel 10y ago
  I frankly don't see how you could come to the conclusion that Angular 2 components are simpler than React components. I mean, in React, a component can be as simple as const MyComponent = () => <span> some markup nonsense </span>;
  - msane 10y ago
    Yup that's the argument mentioned: React is "simpler", "anyone can see"... Brevity isn't simplicity. The simplicity is being easier to install, build, read about, debug, consume APIs with, send data between, talk about to other developers... and yes, "reason" about. myMod.component('Foo', { template: '<h1>{{$and.better.templating}} {{see()}}</h1>', controller: function() { var and = {this_one: 'does_stuff'}; } });
    - thegayngler 10y ago
      This is not easier to reason about than returning jsx IMO... It's only 1 of the ways to build an angular 2 component. The website tutorial is using decorator syntax. Typescript Angular 2 documentation. What's wrong with just learning JavaScript and less Angular specific syntax and tooling. Maybe I'm wrong but I feel like Angular likes to force projects to become big monoliths where people who don't understand the problem being solved are trying to architect a solution for all of the problems. React does have jsx shock and JavaScript tooling fatigue. However, now that React is mature JavaScript tooling decision fatigue should be less of an issue. You aren't relying on one company to solve problems. You have a community solving problems for themselves. As they need it they can add it or take it away.
    - warfangle 10y ago
      Why aren't you just using an interpolated string?
- Silhouette 10y ago
  I recommend avoiding React. I have never seen an ecosystem so bogged down at every turn. It's perfectly possible to just use React on its own, without getting bogged down with all the other buzzword-of-the-week stuff around it. React itself has been reasonably stable for a long time in Web terms. It is much more tightly scoped and smaller in its interface than most JS frameworks. There are a couple of major design trade-offs, which often seem to get overlooked in React advocacy, but if you have a bit of experience using it and understand the practical pros and cons then you can quickly decide whether the balance is favourable for some new project. People who work in React spend way more time fixing toolchain stuff and trying to mix 10 artisanal-crafted "easy to reason about" libraries in order to accomplish tasks which are either solved or not even issues in other component frameworks. Some people who work with React might. Plenty of others don't.
rco8786 10y ago
I hope your not pushing that to any meaningful production environment
- JustSomeNobody 10y ago
  Why? Define "meaningful".
grumblestumble 10y ago
"Over 90% of the time that prototype turns out to be good enough, either because the problem is abandoned or remains at a level where a rewrite isn't worth it." You might want to spend some introspection time on that statement.
- pavlov 10y ago
  What do you mean by that?

fenomas 10y ago

> eschew platforms and libraries and roll my own most of the time That's what nearly everybody does, when they're one person hacking on a one-off project. I like to hate on Big Web Frameworks as much as anyone, but it should be understood that their value isn't replacing your hand-rolled code, their value is to let big 20-person projects avoid having 20 different flavors of hand-rolled code.

pavlov 10y ago
Thing is, complex frameworks like Angular tend to allow for 20 different ways to accomplish the same thing, so they don't really solve the underlying problem: team members still need to agree on a common approach and a shared set of idioms and coding styles. There is a difference though. When there's a big framework involved, discussion will tend towards "Is this the right way to do X in Angular?" rather than "How do we want to solve X?". That may be good or bad, depending on whether you want to build your career around being an "Angular expert" (or a "Rails expert" or "SAP expert" or "COBOL/IMS expert" or any other kind of framework expert).
- buckbova 10y ago
  I picked up Angular quickly, insisted everyone in my group follow this style guide. https://github.com/johnpapa/angular-styleguide https://github.com/johnpapa/angular-styleguide We didn't need an expert.
  - jasonm23 10y ago
    Seems you were lucky that the expert you didn't need had written up a style guide.
    - buckbova 10y ago
      Definitely. We live in wonderful times.
  - thegayngler 10y ago
    I don't like Angular 1.xxx that much because in Angular 1.xxx building simple stuff in JavaScript is a no no. Angular doesn't play nicely with JavaScript. Instead you have to do Angularjs way and write the Angular specific code in your 50 Angular specific HTML attributes. Performance of data intensive apps is particularly lousy in Angular. In my opinion it's a framework written for people who like complexity for complexity's sake. I don't want to be hunting all over my code base just to figure out what is happening in a controller or component. JPs styleguide is awesome!

hajile 10y ago

It's not so much a change in technology as it is a shift in focus. If you or your company needs a basic website, then wordpress will almost always take you as far as you need to go. There's not a huge need for devs and nobody who's good at the web wants to be there because it's a race to the bottom financially. That part of the web (the overwhelming majority I might add) is pretty stagnant with few real changes or advancements having happened in the past decade. Apps failed in that nobody wants to install your app on their device unless it's a game, a free utility, or one of a few popular apps made by large companies. WebOS got the idea of web technologies right, but the devices were too limited. Today, the idea of a web app that runs everywhere is very appealing and much more accessible to clients. All the new frameworks are really targeting this kind of use. Pounding the square that is web apps through the round hole that is the browser is hard, but still better than the alternatives. If you're making a website, jQuery and simple JS is usually all you need. If you're making a web app with complex data and complex UI, you need a framework to keep things sane.

blub 10y ago
Web app with complex data = website that can be done very well with html, css and a server-side language. It's only the complex UI which requires JS frameworks and libraries, but building such a UI is already a losing proposition and the main reason why web programming is getting "unnecessarily complicated". Web developers think that web apps can compete with native applications - they still can't and in the process of trying to get them there, they turned the process of building websites into a mess.
- onion2k 10y ago
  Web app with complex data = website that can be done very well with html, css and a server-side language. Only if you make a baseless assumption about the user's internet connection. Someone whose connection drops out regularly, or who faces periods without a connection at all, is going to hate your server-side app compared to my offline-first progressive web app that they can have cached on their device and that syncs their changes using pouchdb/couchdb. My app will have a ton of JS that yours doesn't, but that extra code makes it work when they're not online. That's a huge advantage. Not all progress is designed for added shininess. Some of the changes that are happening are designed to fix real problems that people face.

notliketherest 10y ago

wow this attitude is so sad! React + Redux - changed my whole outlook on web development and it's actually a joy again. Take a little bit of time, read, learn, figure out a simple webpack script, and you're gonna love life.

kalleboo 10y ago

Most of the web stuff I have to work on is developed once, and then maintained rarely (once a year or so). It's not the kind of project that has continuous development. So whenever I've used a framework or SDK, when it comes time to add a small feature or tweak, I spend more time bringing the project up to date with the latest version of the framework or SDK than I do implementing the feature. Literally every time I update one of our sites using a Facebook SDK, they've changed around how the whole SDK is designed and I have to rewrite basic things like session management.

polishninja 10y ago
I've run into this issue multiple times as well.

blub 10y ago

I think there's a lot of social pressure from rockstar web developers to build and use JS libraries and frameworks. Let's face it, classic front-end web development works fine and is well understood. Doesn't get you into conferences or help you sell courses. So we get the web of today, piles of Javascript and unnecessary complexity all wrapped together with ads and tracking. And excuses about how today's customers expect an app-like experience.

jasonthevillain 10y ago
> And excuses about how today's customers expect an app-like experience Yes. If anyone has evidence of this I'd love to see it.

pbreit 10y ago

I'm still sort of a newbie but I have found it much much easier for me to quickly build my projects on the very very easy to use Web2py Python framework. The things I like are: defining my DB structure in simple code, no routing (routing is implied by file & function names), Python, HTML views with simple embedded code (including full Python if need/want).